Documento que considera el por qué es importante usar métodos y modelados cuando se desea hacer software

1. METODOS Y MODELOS DE DESARROLLO DE SOFTWARE
ENRIQUE TORRESCANO MONTIEL
Herramientas para el Modelado de Software
Introducción
El mundo antiguo de la producción ha quedado en el pasado y ha dado paso (como debe hacerlo) a
nuevas formas de producción que tiene al mundo en jaque, pues los avances en la ciencia y la
tecnología han rebasado las expectativas de lo que se tiene y lo que se necesita.
Los menesteres en cuanto a la producción comenzó sin duda en Europa, específicamente en
Inglaterra, cuando nace el concepto de la Revolución Industrial, que es cuando el hombre sustituye
mano de obra artesanal por máquinas.
No me cabe la menor dudad que en ese tiempo los seres humanos que vieron las primeras
máquinas inventadas, quedaron maravillados ante lo que éstas hacían, ante la manera en que
ayudaban a fabricar algo. De que si la Revolución Industrial aportó elementos negativos como el
inicio en la contaminación ambiental al manejar como combustible algo fósil; el carbón mineral, no
es tema de nuestro trabajo, a nosotros nos interesa el hecho de ver esa evolución en la forma de
hacer algo, algo que ha de beneficiar al hombre, a su mundo, a su forma de producir. Los avances
en la forma de producción cambian con el tiempo y conocemos cosas nuevas que en tiempos muy
antaños ni en idea pertenecieron a la manera de producir algo para el hombre, las empresas y la
sociedad.
Hemos visto, por vivencia o por historia que el hombre, su sociedad y su producción han tenido
un avance creciente que se han modelado en base a los requerimientos del contexto histórico-
laboral-social que se ha tenido y que estos avances han servido de base para hacer nuevas
propuestas en base a lo que el hombre requiere para volver a aumentar su potencial productivo.
Uno de los grandes avances está regido por lo que conocemos como computadoras y por lo que a
ellas las hace trabajar; hardware y software. Centrándonos en el software, tenemos que éste
resurge después de que el hombre define que tal está en crisis, por ahí de los años ´68 y es cuando
el ser inteligente hace el nuevo paradigma en cuanto a la producción del software, enfocándolo y
orientándolo a un usuario.
Entonces, el software renace con una nueva manera de hacerle, de producirle y digo producirle
pues existen las empresas que su potencial de producción está regido por hacer software.
Dentro del nuevo paradigma en la "hechura" del software están presentes referencias teóricas que
le apoyan en su nuevo enfoque, uno de estas referencias se llama modelado del software. El
modelado de software está fuertemente sustentado por las empresas dedicadas a la producción
del mismo, es parte del estudio de varias metodologías, que si bien han sido fuertemente
sustentadas, usadas y desechadas, todas han aportado al menos nuevas ideas y paradigmas en la
evolución en cuanto a la parte intangible de una computadora.
Es pues, el modelado del software nuestro asunto a tratar, de demostrar que funciona, que es útil
al hombre , a las empresas, al software.

2. El hombre, el software y su producción
El desarrollo del software es una parte muy importante en el procesos de producción del ser
humano, tomando el cuenta que el mundo está lleno de empresas y personas que le ocupan y de
los beneficios que éste aporta a la productividad mundial. Hablar de productividad en cuanto al
software no es hablar de algo que someramente ha de funcionar, el software es ahora un parte
importante en la producción del hombre y de sus empresas y, casi no podemos imaginar algo que
se haga sin la intervención del software y, tenemos entonces que definir que el software debe
cubrir las expectativas de las necesidades del hombre, de su mundo y de su producción.
Es aquí cuando se hace necesario que el software pase por etapas en cuanto a su producción y
que sea su producción resultado de un meticuloso desarrollo, culminando con una correcta
aplicación en el ámbito productivo que se requiera.
Y bueno, aquí ya es necesario insertar que se requieren de determinadas herramientas para su
proceso productivo. Esas herramientas se denominan Herramientas para el Modelado del Software.
Y dentro de ello tenemos al tan laureado UML o lenguaje de modelado unificado, que no es otra
cosa que la herramienta que nos ayuda a modelar en las fases de análisis y diseño a un futuro
sistema informático. UML no permite modelar, construir y documentar los elementos que forman
un sistema de software orientado a objetos.
Dentro del proceso de desarrollo del software y tomando en cuenta a UML, tenemos que éste nos
va a aportar una enorme ayuda en cuanto al análisis y diseño de un sistema de información y a
través del uso de UML, podemos identificar y dar respuesta a los siguientes cuestionamientos:
En lo que respecta al el análisis nos permitirá responder a la pregunta “¿qué hay que hacer?”
Sobre el diseño a “¿cómo hacerlo?”
Desde luego que ésta opuesta nos va a orientar a reconocer los fundamentos de una arquitectura
de software eficiente aplicando patrones de diseño.
Y no olvidemos lo importante que es tener la siempre visión del análisis y el diseño orientado a
objetos.
Ahora, uno de los momentos en el modelado del software es el "uso" de los casos de uso
Dentro de este concepto tenemos :
• Los casos de uso es una colección de diagramas y texto que juntos va a documentar como
los usuarios esperan interactuar con el sistema.
• Los casos de uso están centrados en los factores álgidos de éxito, en cuanto a la
funcionalidad que los usuarios necesitan para interactuar.
• La meta del diagrama de caos de uso es proporcionar la explicación grafica de la relación
del sistema y el mundo exterior.
Supongamos que voy a un banco y me decido por usar un cajero automático en vez del
cajero humano y el diagrama del Caso de Uso puede corresponder a la pantalla principal y a
un menú que se despliega y puede consistir en ingresar número confidencial, consulta de
saldo, retiro de efectivo, un pago, una donación. Estas opciones pueden representarse
como un Caso de Uso por separado. El cliente que no pertenece al sistema, sino que le usa,
está asociado con cada uno de los Casos de Uso; que están dentro del sistema que como
usuario desea usar.

3. Los casos de uso, como parte esencial en el modelado usando UML, contiene elementos en
sus diagramas, son:
El actor, representado por un monigote.
El rectángulo que representa al sistema y los limites dentro de los cuales interactuará el
actor y el sistema
Existe la dependencia, identificada con una flecha con línea pautada
La asociación, que es la línea que une desde afuera hacia adentro al actor y al caso de uso
dentro del sistema
Ahora veamos a la generalización, identificada con una flecha con línea continua
El mismo caso de uso, identificado con un ovalo; ahí se integran los verbos que marcaran
las acciones que se esperan del actor interactuando con el sistema, ejemplo compra
zapatos.
• Es necesario hacer la diferencia que a pesar de que cada Caso de Uso soporta un proceso,
éstos se centran en la meta, no en el proceso. Si vemos los Casos de Uso de esta forma, el
sistema se especifica como un juego de requerimientos más que una solución. No se dice
como trabaja el sistema, sino lo que debe ser capaz de hacer. Ejemplo: voy al súper, compro
un cereal, paso a caja, pago con medio electrónico, me entregan el producto y me retiro.
Para nada vi como el o la cajera me cobró, no vi para nada como se daba la comunicación
entre mi tarjeta y la base de datos de mi banco.
En UML los casos de uso son los principales medios para capturar la funcionalidad del sistema
desde la perspectiva del usuario y puede llegar a remplazar al documento llamado requisitos
funcionales.

4. En UML los componentes básicos de los diagramas de casos de uso y sus representaciones
son:
Reforzando el cuadro, tenemos que...
El Sistema: Establece el límite del sistema en relación con los actores que le van a usar.
El Actor: Es un rol que puede realizar una persona, otro sistema, un dispositivo.
El Caso de Uso: Identifica una característica clave del sistema, expresa una meta (no el
cómo) que el sistema debe lograr.
La Asociación: identifica la asociación entre el (los) actor (es) y Casos de Uso. Cada
asociación es un diálogo que debe explicarse con la narrativa del Caso de Uso.
La Dependencia: Nos permite Identificar una posible comunicación entre dos Casos de Uso.
La Generalización: Concreta una relación entre dos actores ó entre dos Casos de Uso,
cuando uno de los casos hereda las propiedades del otro.
UML cuenta con varios diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.
• Diagramas de Estructura:
• Diagramas de Clases
• Diagramas de Componentes
• Diagramas de Objetos
• Diagrama de Estructura Compuesta
• Diagrama de Despliegue
• Diagrama de Paquetes
• Diagramas de Actividades
• Diagramas de Casos de Uso
• Diagramas de Estados
• Diagramas de Secuencia
• Diagrama de Comunicación – Versión Simplificada de Diagrama de Colaboración
• Diagrama de Tiempos
• Diagrama Global de Interaciones o Diagrama de Vista de Interacción

5. Star UML
Algo hasta ahora desconocido por mi persona, investigando encuentro que..
StarUML es una herramienta usada para el modelamiento de software apoyado en los
estándares UML (Unified Modeling Language) y MDA (Model Driven Arquitecture)
Se cuenta entre sus antecedentes que fue un producto comercial y posteriormente se
proyecto como un proyecto comercial de licencia abierta
Primeramente se le llamó Plastic.
Ya como software le licencia abierta, hereda las notables características de la primer versión
comercial y con el paso del tiempo ha ido mejorando sus ya de por sí notables
características.
Veamos algunos beneficios
Brinda un soporte al uso y permite la creación de:
 Diagrama de casos de uso
 Diagrama de clase
 Diagrama de secuencia
 Diagrama de colaboración.
 Diagrama de estados
 Diagrama de actividad.
 Diagrama de componentes
 Diagrama de despliegue.
 Diagrama de composición estructural (UML 2.0)
Además, al uso nos permite definir los elementos particulares para los diagramas, que no
necesariamente pertenezcan al estándar de UML,
Brinda la capacidad de generar código a partir de los diagramas y viceversa. Funciona muy
bien para los lenguajes c++, c# y java.
Permite generar documentación en formatos Word, Excel y PowerPoint sobre los diagramas.
Patrones GoF (Gang of Four) , EJB (Enterprise JavaBeans) y personalizados.
Podemos crear Plantillas de proyectos.
Existe la posibilidad de crear plugins para el programa.

6. Conclusión:
El saber diferenciar entre hacer un software y modelar con herramientas para el modelado del
software, hace una diferencia enorme entre el producto final que se ha de obtener, sabiendo que el
producto va dirigido a una empresa/persona y más, que la dirección está encausada a la
productividad.
Es menester de un desarrollador saber hacer esta diferencia y hacerla aplicar, pues de que él
interactué con sus conocimientos, con sus clientes, con sus habilidades y herramientas,
dependerá la calidad de su trabajo y de sus productos.
No es necesario ser un verdadero inventor de lo que se requiere, sabemos que la cuestión teórica
ya está incluida en la preparación profesional, que la praxis es necesaria y que sólo falta el juicio
ético y moral de quien va a de prestar un servicio a un cliente.
A T E N T A M E N T E
Enrique Torrescano Montiel