UNIVERSIDAD DE MACHALA

FACULTAD DE CIENCIAS SOCIALES

ESCUELAS DE:
CIENCIAS DE LA EDUCACIN CARRERA:

DOCENCIA EN INFORMATICA

PROGRAMA DEL MDULO:

ORIENTADO OBJETOS

CON

UML

FACILITADOR:

ING. TITO JAVIER POLO CACAO

Anlisis de Sistemas

Anlisis de Sistemas

INDICE
1.3 TCNICAS DE COMUNICACIN............................................... 9 1.4 TCNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNA . 10

Anlisis de Sistemas

INTRODUCCIN El presente trabajo est dirigido a mejorar el entendimiento del docente en informtica, en primer lugar, de los conceptos bsicos de los elementos que rodean a la actividad del anlisis de sistemas, y dar un enfoque prctico de los procesos y tcnicas utilizadas para alcanzar mejor comprensin del funcionamiento de los procesos que se pretendern automatizar, modelando ideas y conceptos que es en s de lo que trata el anlisis de sistemas. El mundo globalizado de hoy, rodeado de una vertiginosa evolucin tecnolgica, exige a los profesionales, ya no del maana si no de hoy, un conocimiento pleno de tecnologas computacionales, tanto que actualmente se acua el trmino Analfabetismo informtico, y es labor del docente en informtica preparar a las personas para enfrentar este mundo instaurado con estructura tecnolgica; uno de los aspectos donde tiene mayor influencia el desarrollo tecnolgico es la automatizacin de los procesos ms variados de las actividades comunes de diversos tipos de gestin, y el entender la forma de transformar estos procesos a conceptos y modelos que puedan ser traducidos a un lenguaje informtico es una de las herramientas ms poderosas de la actualidad, el presente mdulo tiene como objetivo servir de gua para conocer las tcnicas utilizadas para dichas transformaciones. El mdulo trata en su primera parte de dejar en claro ideas y conceptos, muchas veces tergiversados acerca de los elementos que rodean a un sistema automatizado, luego nos da a conocer los diferentes modelos que existen para de una forma global cubrir proyectos informticos de los cuales forma, es una fase ms el tema en el que se centra este mdulo, finalmente se indica el proceso utilizado para desarrollar un proyecto de anlisis de sistemas.

Anlisis de Sistemas

OBJETIVOS

OBJETIVO GENERAL
Desarrollar las habilidades y destrezas en cada uno de los estudiantes con el

uso de las herramientas informticas para el desarrollo del Anlisis de Sistema, logrando una aplicacin eficiente y eficaz.

OBJETIVOS ESPECIFICOS
Identificar las fases del Anlisis de Sistema, sus principales conceptos y

tcnica, para que una correcta introduccin en su aplicacin.

Reconocer en qu consiste la orientacin a Objetos, describiendo sus

conceptualizaciones, para su fcil utilizacin.

Manejar correctamente el lenguaje Unificado de datos, para una eficiente

aplicacin en el desarrollo del Anlisis de Sistemas.

Anlisis de Sistemas

MODULO Anlisis de Sistemas. Unidades del Mdulo: 1.- Anlisis y diseo de sistemas. 2.- Anlisis y diseo Orientado a objetos. 3.- Introduccin a lenguaje de modelamiento unificado U.M.L.

Anlisis de Sistemas

UNIDAD I Anlisis y diseo de sistemas. 1. Introduccin Todo gira en torno a una visin. Un sistema complejo toma forma cuando alguien tiene la visin de cmo la tecnologa puede mejorar las cosas. Los desarrolladores tienen que entender completamente la idea y mantenerla en mente mientras crean el sistema que le den forma. El xito de los proyectos de desarrollo de aplicaciones o sistemas se debe a que sirven como enlace entre quien tiene la idea y eld esarrollador. El UML (Lenguaje unificado de Modelaldo) es una herramienta que cumple con sta funcin, ya que le ayuda a capturar la idea de un sistema para comunicarla posteriormente a quien est involucrado en su proceso de desarrollo; esto se lleva a cabo mediante un conjunto de smbolos y diagramas. Cada diagrama tiene fines distintos dentro del proceso de desarrollo. El objetivo de ste texto gua es darle las bases sobre el UML. Cada jornada presentar ejemplos para su mejor comprensin e incluir ejercicios que le permitan que le permitan practicar sus conocimientos recin adquiridos. 1.1. Anlisis.- Accin de dividir una cosa o problema en tantas partes como sea posible, para reconocer la naturaleza de las partes, las relaciones entre estas y obtener conclusiones objetivas del todo. 1.2. Sistemas.-Un sistema es una reunin o conjunto de elementos relacionados.

1.2.1. TIPOS DE SISTEMAS Existen dos categoras bsicas en la clasificacin de sistemas:

Sistemas naturales.

Creados por el hombre

Sistemas hechos por el hombre.

Anlisis de Sistemas

En lo que respecta a los sistemas hechos por el hombre existen una gran diversidad de sistemas construidos, organizados y mantenidos por humanos, tales como: sistemas sociales, sistemas de transporte. En la actualidad, la mayora de estos sistemas incluyen las computadoras pero es importante sealar que dichos sistemas existan antes de que hubiera computadoras; de hecho, algunos sistemas continan por completo sin computarizar y podran permanecer as durante muchas dcadas ms. Otros contienen a la computadora como componente, pero tambin incluyen uno o ms componentes no computarizados (o manuales). Un sistema de informacin es el sistema de personas, registros de datos y actividades que procesa los datos y la informacin en cierta organizacin, incluyendo manuales de procesos. 1.2.2. Sistema de informacin.- Un sistema de informacin es el sistema de personas, registros de datos y actividades que procesa los datos y la informacin en cierta organizacin. 1.2.3. Sistema de informacin automatizada.- Los sistemas de informacin computarizados, incluyendo equipos (hardware), programas (software) y personal, se generarn a partir de los requerimientos formalmente establecidos por los usuarios. Sistema de Informacin Bsico en las Empresas Recursos humanos. Gestin comercial. Gestin contable y financiera De control de las existencias y de produccin

SISTEMAS BASICOS DE LAS EMPRESAS

RECURSOS HUMANOS

CONTABILIDAD

EXISTENCIAS

COMERCIAL

Anlisis de Sistemas

1.3 TCNICAS DE COMUNICACIN

El anlisis de requisitos del software siempre empieza con la comunicacin entre dos o ms partes. Un cliente tiene un problema que pretende sea resuelto con una solucin basada en computadora. Un desarrollador responde a la solicitud de ayuda del cliente. La comunicacin ha empezado. Pero como ya hemos sealado, el camino de la comunicacin al entendimiento est a menudo lleno de baches. Inicio del proceso

La tcnica de anlisis ms usada para cubrir el hueco de comunicacin entre el cliente y el desarrollador y para empezar el proceso de comunicacin es llevar a cabo una reunin o entrevista preliminar. La primera reunin entre el el analista y el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qu decir o preguntar; los dos estn preocupados de que lo que digan sea malentendido; ambos piensan qu pasar (los dos pueden tener expectativas radicalmente diferentes); los dos estn deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un xito. Sin embargo, hay que empezar la comunicacin. Gause y Weinberg sugieren que el analista empiece preguntando cuestiones de contexto libre. Es decir, un conjunto de preguntas que llevarn a un entendimiento bsico del problema, qu solucin busca, la naturaleza de la solucin que se desea y la efectividad del primer encuentro. El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo, el analista podra preguntar: Quin est detrs de la solicitud de este trabajo? Quin utilizar la solucin? Cul ser el beneficio econmico del xito de una solucin? Hay alguna otra alternativa para la solucin que necesita?

El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sobre la solucin:

10

Anlisis de Sistemas

Cmo caracterizara una buena salida (resultado) generada para una buena solucin? A qu tipos de problema(s) va dirigida esta solucin? Puede mostrarme (o describirme) el entorno en que se utilizar la solucin? Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la solucin?

El ltimo conjunto de preguntas se concentra en la eficacia de la reunin. Gauge y Weinberg las denominan meta-preguntas y proponen la siguiente lista (abreviada):

Es usted la persona adecuada para responder a estas preguntas? Sus respuestas son oficiales? Son adecuadas mis preguntas para el problema que tiene usted? Estoy preguntando demasiado? Hay alguien ms que pueda proporcionar informacin adicional? Hay algo ms que debera preguntarle? Estas preguntas (y otras) ayudarn a romper el hielo e iniciar la comunicacin tan esencial para el xito del anlisis. Pero el formato de reunin tipo pregunta y respuesta" no es un enfoque que haya tenido mucho xito. De hecho, esta sesin de preguntas y respuestas debera emplearse solamente en el primer encuentro y sustituirse despus por una modalidad que combine elementos de resolucin del problema, negociacin y especificacin. En la siguiente seccin se presenta un enfoque a reuniones de este tipo.

1.4 TCNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNA APLICACIN.

11

Anlisis de Sistemas

Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de nosotros y ellos. En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio territorio y se comunica a travs de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este mtodo no funciona muy bien. Abundan los malentendidos, se omite informacin importante y nunca se establece una buena relacin de trabajo.

Con estos problemas en mente es por lo que algunos investigadores independientes han desarrollado un enfoque orientado al equipo para la reunin de requisitos que se aplica durante las primeras fases del anlisis y especificacin. Denominadas Tcnicas para facilitar las especificaciones de la aplicacin (TFEA), este enfoque es partidario de la creacin de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solucin [ZAH90]. Hoy en da, las TFEA son empleadas de forma general para los sistemas de informacin, pero la tcnica ofrece un potencial de mejora en aplicaciones de todo tipo. Se han propuesto muchos enfoques diferentes de TFEA. Cada uno utiliza un escenario ligeramente diferente, pero todos aplican alguna variacin en las siguientes directrices bsicas: La reunin se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores. Se establecen normas de preparacin y de participacin. Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes pero lo suficientemente informal como para animar el libre flujo de ideas. Un coordinador (que puede ser un cliente, un desarrollador o un tercero) que controle la reunin. Se usa un mecanismo de definicin (que puede ser hojas de trabajo, grficos, carteles o pizarras).

El objetivo es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solucin en una atmsfera que permita alcanzar el objetivo.

12

Anlisis de Sistemas

Para comprender mejor el flujo de acontecimientos tal y como ocurren en una reunin TFEA, presentamos un pequeo escenario que esboza la secuencia de acontecimientos que llevan a la reunin, los que ocurren en la reunin y los que la siguen. En las reuniones iniciales entre el desarrollador y el cliente se dan preguntas y respuestas bsicas que ayudan a establecer el mbito del problema y la percepcin global de una solucin. Fuera de estas reuniones iniciales, el cliente y el desarrollador escriben una solicitud de producto de una o dos pginas. Se selecciona lugar, fecha y hora de reunin TFEA y se elige un coordinador. Se invita a participar a representantes de ambas organizaciones; la del cliente y la de desarrollo. Se distribuye la solicitud de producto a los asistentes antes de la fecha de reunin. Mientras se revisa la solicitud das antes de la reunin, se pide a todos los asistentes que hagan una lista de objetos que formen parte del entorno del sistema, otros objetos que debe producir el sistema y objetos que usa el sistema para desarrollar sus funciones. Adems, se pide a todos los asistentes que hagan otra lista de servicios, (procesos o funciones) que manipulan o interactan con los objetos. Finalmente, se desarrollan tambin listas de restricciones (p. ej.: costes, tamao, peso) y criterios de rendimiento (p. ej,: velocidad, precisin). Se informa a los asistentes que no se espera que las listas sean exhaustivas, pero que s que reflejen su punto de vista del sistema. Por ejemplo, imagnese que a un equipo de trabajo TFEA de una compaa de productos para el consumidor se le ha dado la siguiente descripcin del producto:

Nuestras investigaciones indican que el mercado de sistemas de seguridad para el hogar est creciendo a un ritmo del 40 por ciento anual. Nos gustara entrar en este mercado construyendo un sistema de seguridad para el hogar basado en un microprocesador que proteja y/o reconozca varias situaciones indeseables tales como irrupciones ilegales, fuego, inundaciones y otras. El producto, provisionalmente llamado Hogar Seguro, utilizar los sensores adecuados para detectar cada situacin, puede programarse por el propietario del hogar y llamar automticamente a una agencia de vigilancia cuando se detecte alguna de estas situaciones. En realidad, se proporcionara considerablemente ms informacin en esta fase. Pero incluso con informacin adicional, habra ambigedades presentes, existirn

13

Anlisis de Sistemas

omisiones probablemente y podran ocurrir errores. Por ahora, la descripcin de producto anterior bastar. El equipo TFEA est compuesto por representantes de mercadotecnia, ingeniera del software y del hardware y de la fabricacin. Participar un coordinador externo. Todos los componentes del equipo TFEA (Figura 1.1) desarrollan las listas descritas anteriormente. Los objetos descritos para Hogar Seguro podran incluir detectores de humo, sensores de ventanas y puertas, detectores de movimientos, una alarma, un acontecimiento (se ha activado un sensor), un panel de control, una pantalla, nmeros de telfono, una llamada de telfono, etc. La lista de servicios podra incluir la instalacin de la alarma, vigilancia de los sensores, marcado de telfono, programacin del panel de control y lectura de la pantalla (fjese que los servicios actan sobre los objetos). De igual manera, todos los asistentes TFEA desarrollarn una lista de restricciones (p. ej.: el sistema debe tener un coste de fabricacin de menos de 200$. debe tener una interfaz amigable con el usuario y debe conectar directamente con una lnea telefnica estndar) y de criterios de rendimiento (p. ej: un acontecimiento detectado por un sensor debe reconocerse en un segundo; se debera implementar un esquema de prioridad de acontecimientos).

Coordinador Secretario Cliente(s) Desarrollador(s)

Fig. 1.1 La Reunin TFEA Cuando empieza la reunin, el primer tema de estudio es la necesidad y justificacin del nuevo producto, pues todo el mundo debera estar de acuerdo en que el desarrollo (o adquisicin) del producto est justificada. Una vez que se ha conseguido el acuerdo, cada participante presenta sus listas para su estudio. Las listas pueden exponerse en las paredes de la habitacin usando largas hojas de

14

Anlisis de Sistemas

papel, pinchadas o pegadas, o escritas en una pizarra. Idealmente debera poderse manejar separadamente cada entrada de las listas para poder combinarlas, borrarlas o aadir otras. En esta fase, est estrictamente prohibido el debate o las crticas. Una vez que se han presentado las listas individuales sobre un tema, el grupo crea una lista combinada. La lista combinada elimina las entradas redundantes y aade las ideas nuevas que se les ocurran durante la presentacin, pero no se elimina nada ms. Cuando se han creado las listas combinadas de todos los temas, sigue el estudio moderado por el coordinador. La lista combinada es ordenada, ampliada o redactada de nuevo para reflejar apropiadamente el producto o sistema que se va a desarrollar. El objetivo es desarrollar una lista de consenso por cada tema (objetos, servicios, restricciones y rendimiento). Despus estas listas se ponen a parte para utilizarlas posteriormente. Una vez que se han completado las listas de consenso, el equipo se divide en subequipos: cada uno trabaja para desarrollar una mini-especificacin de una o ms entradas de cada lista. La mini-especificacin es una elaboracin de la palabra o frase contenida en una lista. Por ejemplo, la mini-especificacin del objeto panel de control de Hogar Seguro podra ser: montado en la pared; Tamao aproximadamente de 9x5 pulgadas; contiene el teclado estndar de 12 teclas y teclas especiales; contiene una pantalla LCD de la forma mostrada en el bosquejo (no presentado aqu); Toda la interaccin del cliente se hace a travs de las teclas usadas para activar o desactivar el sistema; Software para proporcionar una directriz de empleo, recordatorios, etc. conectado a todos los sensores. Cada subequipo presenta entonces sus mini-especificaciones a todos los asistentes TFEA para estudiarlas. Se realizan nuevos aadidos, eliminaciones y se sigue elaborando. En algunos casos, el desarrollo de algunas mini-especificaciones descubrir nuevos objetos, servicios, restricciones o requisitos de rendimiento que se aadirn a las lisias originales. Durante todos los estudios, el equipo sacar a relucir aspectos que no podrn resolverse durante la reunin. Se har una lista de estas ideas para tratarlas ms adelante. Una vez que se han completado las mini-especificaciones, cada asistente de la TFEA hace una lista de criterios de validacin del producto/sistema y presenta su lista al equipo. Se crea as una lista de consenso de criterios de validacin.

15

Anlisis de Sistemas

Finalmente, uno o ms participantes (o algn tercero) es asignado para escribir el borrador entero de especificacin con todo lo expuesto en la reunin TFEA. TFEA no es la panacea de los problemas que se encuentran en las primeras reuniones de requisitos, pero el enfoque de equipo proporciona las ventajas de muchos puntos de vista, estudio y refinamiento instantneo y un paso adelante hacia el desarrollo de una especificacin.

1.5 ESPECIFICACIN DE REQUISITOS (ERS). Uno de los objetivos principales del Anlisis de Sistemas es la especificacin de requisitos, es decir, que se detalle minuciosamente las necesidades que debe cubrir y las especificaciones a las que tiene que ajustarse el software a desarrollar. Pero estas especificaciones estn debidamente normadas y el analista debe ajustarse al estndar. Para documentar la Especificacin de Requisitos Software (ERS) del Sistema Informtico se ha de trabaja con el apoyo de los usuarios y responsables de la Empresa. Esta especificacin ser diseada basndose en normas dadas por el estndar IEEE Recommended Practice for Software Requirements Specification ANSI/IEEE 830, 1998, el cual propone un esquema como el siguiente: 1.3 TCNICAS DE COMUNICACIN............................................... 9 1.4 TCNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNA . 10

1.6 ESTUDIO DE VIABILIDAD Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materializacin sin tener prdidas econmicas y frustracin profesional. La viabilidad y el anlisis de riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro reas principales de inters: 1. 6.1 Viabilidad econmica. Una evaluacin de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado.

16

Anlisis de Sistemas

1.6.2. Viabilidad Tcnica. Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. 1.6.3. Viabilidad Legal. Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que se podra incurrir al desarrollar el Sistema.

Alternativas. Una evaluacin de los enfoques alternativos del desarrollo del producto o Sistema. El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia. 1.7 ANLISIS ECONMICO Y TCNICO. El anlisis econmico incluye lo que llamamos, el anlisis de costos - beneficios, significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema.

Muchas veces en el desarrollo de Sistemas de Computacin estos son intangibles y resulta un poco dificultoso evaluarlo, esto vara de acuerdo a las caractersticas del Sistema. El anlisis de costos - beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto.

En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de mantenimiento y productividad. Los resultados obtenidos del anlisis tcnico son la base para determinar sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfectamente unas con otras.

17

Anlisis de Sistemas

18

Anlisis de Sistemas

UNIDAD II

Anlisis y diseo Orientado a objetos. 2. Introduccin al Anlisis y Diseo Orientado a Objetos Centrarse en el qu. Identificar los requisitos: documentos de anlisis. Entrevistas. Identificar requisitos funcionales y no funcionales (ej.: rendimiento, fiabilidad) Especificar los requisitos: documento de especificacin de requisitos. Documento tcnico. Organizacin y clasificacin de los requisitos. Analizar: Modelos de anlisis. Estudio de posibles escenarios: casos de uso. Otras tcnicas: fichas CRC, orientados al flujo, etc. Validar

19

Anlisis de Sistemas

2.1 PASOS PARA EL ANALISIS

20

Anlisis de Sistemas

2.2 ANALISIS BASADOS EN ESCENARIOS

21

Anlisis de Sistemas

2.3 VENTAJAS DE PROGRAMACION ORIENTADAS A OBJETOS

Ventajas de la abstraccin de datos + disciplina de programacin Reutilizacin de cdigo, mantenimiento y extensin de las aplicaciones. Potencia del lenguaje: herencia, polimorfismo. Reflejar conceptos de problemas reales. Ms fcil de utilizar?. La Programacin Orientada a Objetos (POO) permite realizar grandes programas mediante la unin de elementos ms simples, que pueden ser diseados y comprobados de manera independiente del programa que va a usarlos. Muchos de estos elementos podrn ser reutilizados en otros programas. A estas piezas, mdulos o "componentes", que interactan entre s cuando se ejecuta un programa, se les denomina objetos. Estos objetos contienen tanto datos como las funciones miembros que actan sobre esos datos. Durante la ejecucin del programa, los objetos interactan pasndose mensajes y respuestas. Sucede a menudo que hay que utilizar varios ejemplares anlogos de un determinado elemento u objeto (por ejemplo varias ventanas en la pantalla del PC, varios usuarios, varios clientes, varias cuentas corrientes de un banco, etc.). La definicin genrica de estos objetos Anlogos se realizar mediante la clase. As, una clase contiene una completa y detallada descripcin de la informacin y las funciones que contendr cada objeto de esa clase. Las clases de C++ se pueden ver como una generalizacin de las estructuras 2.4 Lenguajes orientados a objetos Simula (1967) Smalltalk (1980) C++ (1983, 1990) Object Pascal (1988) Lisp CLOS (1989) Java (1995, 1997, 1998)

22

Anlisis de Sistemas

2.5 Elementos de la programacin Orientada a objetos Objetos: atributos + mtodos Mtodos: operaciones sobre los objetos Clases: categoras de objetos con propiedades y operaciones comunes Jerarquas de clases En algunos lenguajes las clases son objetos, en otros no Relaciones, objetos compuestos 2.6 OBJETOS, OBJETOS POR DOQUIER Los objetos concretos y virtuales, estn a nuestro alrededor, ellos conforman nuestro mundo. El software actual simula el mundo (o un segmento de l), y los programas, por lo general, imitan a los objetos del mundo. Si comprende algunas cuestiones bsicas de los objetos, entender cmo se deben mostrar stos en las representaciones de software. Antes que nada, un objeto es la instancia de una clase (o categora). Usted y yo, por ejemplo, somos instancias de la clase persona. Un objeto cuenta con una estructura, es decir atributos (propiedades) y acciones. Las acciones son todas las actividades que el objeto es capaz de realizar. Los atributos y acciones, en conjunto, se conocen como caractersticas o rasgos. Como objeto de la clase Persona, usted y yo contamos con los siguientes atributos: altura, peso y edad (puede imaginar mucho ms). Tambin realizamos las siguientes tareas: comer, dormir, leer, escribir, hablar, trabajar, etc. Si tuviramos que crear un sistema que maneje informacin acerca de personas, sera muy probable que incorporramos algunos de sus atributos y acciones en nuestro software. En el mundo de la orientacin a objetos, una clase tiene otro propsito adems de la categorizacin. En realidad es una plantilla para fabricar objetos. Imagnelo como un molde de galletas que produce muchas galletas. Ejemplo: si en una clase Lavadora se indica la marca, el modelo, el nmero de serie y la capacidad (junto con las acciones de agregar ropa, agregar detergente y sacar ropa), tendr un mecanismo para fabricar nuevas instancias a partir de su clase; es decir, podr crear nuevos objetos.

23

Anlisis de Sistemas
En uso de orientacin a objetos, ver que los nombres de clases, como lavadora, se escribirn como Lavadora, y si constara de dos palabras se escribira como LavadoraIndustrial, y las caractersticas como nmero de Serie se escribirn como numeroSerie.

Lavadora marca modelo numeroSerie capacidad agreagarRopa() agregarDetergente() sacarRopa()

Figura 2.1 La clase Lavadora (modelo original) es una plantilla para generar nuevas instancias de Lavadoras.

Es importante que recuerde que el propsito de la orientacin a objetos es desarrollar software que refleje particularmente (es decir, que modele) un esquema del mundo. Entre ms atributos y acciones tome en cuenta, mayor ser la similitud de su modelo con la realidad. En el ejemplo de la lavadora, tendr un modelo ms exacto si incluye los siguientes atributos: volumen del tambor, cronmetro interno, motor y velocidad del motor. Podra hacerlo ms preciso si incluye las acciones las acciones de agregar blanqueador, cronometrar el remojo, cronometrar el lavado, cronometrar el enjuague y cronometrar el centrifugado.

Lavadora marca modelo numeroSerie capacidad volumenTambor cronometroInterno motor velocidadMotor

Figura 2.2 La adicin de atributos y acciones al modelo lo acerca a la realidad

agreagarRopa() agregarDetergente() sacarRopa() agregarBlanqueador() cronometrarRemojo() cronometrarLavado() cronometrarEnjuague() cronometrarCentrifugado()

24

Anlisis de Sistemas

ALGUNOS CONCEPTOS La orientacin a objetos se refiere algo ms que solo atributos y acciones; tambin considera otros aspectos conocidos como: Abstraccin, herencia, poliformismo y encapsulamiento o encapsulacin. As como tambin lo son: el envo de mensajes, las asociaciones y la agregacin.

2.7 ABSTRACCIN La Abstraccin se refiere a quitar las propiedades y acciones de un objeto para dejar solo aquellas que sean necesarias. Qu significa esto ltimo?

Diferentes tipos de problemas requieren distintas cantidades de informacin, an si estos problemas pertenecieran a un rea en comn. En la segunda fase de la creacin de la clase Lavadora, se podran agregar ms atributos y acciones que en la primera fase vale la pena?

Valdra la pena si usted pertenece al equipo de desarrollo que generar finalmente la aplicacin que simule con exactitud lo que hace una lavadora. Un programa de este tipo (que podra ser muy til para los ingenieros de diseo que actualmente estn trabajando en el diseo de una lavadora) deber ser tan completo que permita obtener predicciones exactas respecto a lo que ocurrira cuando se fabrique la lavadora, funcione a toda su capacidad y lave la ropa. De hecho para este caso podra quitar el atributo del nmero de serie, dado que posiblemente no ser de mucha ayuda. Por otra parte si va a generar un software que haga un seguimiento de las transacciones en una lavandera que cuente con diversas lavadoras, posiblemente no valdr la pena. En este programa no necesitar todos los atributos detallados y operaciones del prrafo anterior, no obstante, quiz necesite incluir el nmero de serie de cada objeto lavadora. En cualquier caso con lo que se quedar luego de tomar su decisin respecto a lo que incluir o desechar, ser una abstraccin de una lavadora.

25

Anlisis de Sistemas

2.8 HERENCIA

Como ya se mencion anteriormente, una clase es una categora de objetos (y en el mundo del software, una plantilla sirve para crear otros objetos). Un objeto es una instancia de una clase. Esta idea tiene una consecuencia importante: como instancia de una clase, un objeto tiene todas las caractersticas de la clase de la que proviene. A esto se le conoce como Herencia. No importa que atributos y acciones decida usar de la clase Lavadora, cada objeto de la clase heredar dichos atributos y operaciones. Un objeto no solo hereda una clase, sino que una clase tambin puede heredar de otra. Las lavadoras, refrigeradoras, lava platos, licuadoras, radios y planchas son clases y forman parte de una clase ms genrica llamada: Electrodomsticos. Un electrodomstico cuenta con los atributos de interruptor y cable elctrico, y las operaciones de encendido y apagado. Cada una de las clases Electrodomstico heredar los mismos atributos; por ello, si sabe que algo es un electrodomstico, de inmediato sabr que cuenta con los atributos y acciones de la clase Electrodomstico.

Otra forma de explicarlo es que la lavadora, refrigerador, licuadoras y cosas por el estilo son subclases de la clase Electrodomstico. Podemos decir que la clase Electrodomstico es una superclase de todas las dems.

26

Anlisis de Sistemas

Figura 2.3. Los electrodomsticos heredan los atributos y las acciones de la clase Electrodomstico. Cada electrodomstico es una subclase de la clase Electrodomstico. La clase Electrodomstico es una superclase de cada subclase.

La herencia no tiene que terminar aqu. Por ejemplo, Electrodomstico es una subclase de Artculos del Hogar, como muestra la siguiente figura. Otra de las subclases de Artculos del hogar podra ser Mobiliario, que tendr sus propias subclases. Figura 2.4. Las superclases tambin pueden ser subclases y heredar de otras superclases.

2.9 POLIFORMISMO En ocasiones una operacin tiene el mismo nombre en diferentes clases. Por ejemplo, podr abrir una puerta, una ventana, un peridico, un regalo o una cuenta

27

Anlisis de Sistemas

de banco, en cada uno de estos casos, realizar una operacin diferente. En la orientacin a objetos, cada clase sabe cmo realizar tal operacin. Esto es el poliformismo. Figura 2.5. En el poliformismo, una operacin puede tener el mismo nombre en diversas clases y funcionar distinto en cada una.

En primera instancia, parecera que este concepto es ms importante para los desarrolladores de software que para los modeladores, ya que los primeros tienen que crear el software que implemente tales mtodos en los programas de computacin, y deben estar conscientes de diferencias importantes entre las operaciones que pudieran tener el mismo nombre. Y podrn generar clases de software que sepan lo que se suponen que harn. No obstante el Poliformismo tambin es importante para los modeladores ya que les permite hablar con el cliente (quien est familiarizado con la seccin del mundo que ser modelada) en las propias palabras y terminologas del cliente. En ocasiones, las palabras y terminologa del cliente nos conducen a palabras de accin (como abrir) que pueden tener ms de un significado. El Poliformismo permite al modelador mantener tal terminologa sin tener que crear palabras artificiales para sustentar una unicidad innecesaria de los trminos.

2.10 ENCAPSULAMIENTO En cierto comercial televisivo, dos personas discuten acerca de todo el dinero que ahorraran si marcaran un prefijo telefnico en particular antes de hacer una llamada de larga distancia. Uno de ellos pregunta con incredulidad: Cmo funciona? Y el otro responde: Cmo hacen que las rosetas de maz estallen?. A quin le importa?

28

Anlisis de Sistemas

La esencia del encapsulamiento (o encapsulacin) es que cuando un objeto trae consigo su funcionalidad, esta ltima se oculta. Por lo general la mayora de la gente que ve la televisin no sabe o no se preocupa de la complejidad electrnica que hay detrs de la pantalla ni de todas las operaciones que tienen que ocurrir para mostrar una imagen en la pantalla. La televisin hace lo que tiene que hacer sin mostrarnos el proceso necesario para ello, por suerte, la mayora de los electrodomsticos funcionan as. Figura 2.6 Los Objetos encapsulan lo que hacen; es decir, ocultan la funcionalidad interna de sus operaciones, de otros objetos y del mundo exterior.

Cul es la importancia de esto? En el mundo del Software, el encapsulamiento permite reducir el potencial de errores que pudieran ocurrir. En un sistema que consta de objetos, stos dependen unos de otros en diversas formas. Si uno de ellos falla y los especialistas de software tienen que modificarlo de alguna forma, el ocultar sus operaciones de otros objetos significar que tal vez no ser necesario modificar los dems objetos. En el mundo real, tambin ver la importancia del encapsulamiento en los objetos con los que trabaje. Por ejemplo el monitor de su computadora, en cierto sentido, oculta sus operaciones de la CPU, es decir, si algo falla en su monitor, lo reparar o lo reemplazar; pero es muy probable que no tenga que reparar o reemplazar la CPU al mismo tiempo que el monitor. Ya que estamos en el tema, existe un concepto relacionado. Un objeto oculta lo que hace a otros objetos y al mundo exterior. Por lo cual al encapsulamiento tambin se lo conoce como ocultamiento de la informacin. Pero un objeto tiene que presentar un rostro al mundo exterior para poder iniciar sus operaciones. Por ejemplo, la televisin tiene diversos botones y perillas en s misma o en el control remoto. Una lavadora tiene diversas perillas que le permiten establecer los niveles de

29

Anlisis de Sistemas

temperatura y agua. Los botones y perillas e la televisin y de la lavadora se conocen como interfaces.

2.11 ENVO DE MENSAJES En un sistema los objetos trabajan en conjunto. Esto se logra mediante el envo de mensajes entre ellos. Un objeto enva a otro un mensaje para realizar una operacin, y el objeto receptor ejecutar la operacin. Un televisor y su control remoto pueden ser un ejemplo muy intuitivo del mundo que nos rodea. Cuando desea ver un programa de televisin, busca el control remoto, se sienta en su silla favorita y presiona el botn de encendido. Qu ocurre? El control remoto le enva, literalmente, un mensaje al televisor para que se encienda. El televisor recibe el mensaje, lo identifica como una peticin para encenderse y as lo hace. Cuando desea ver otro canal, presiona el botn correspondiente del control remoto, mismo que enva otro mensaje al televisor (cambiar de canal). El control remoto tambin puede comunicar otros mensajes como ajustar el volumen, silenciar y activar los subttulos. Volvamos a las interfaces. Muchas de las cosas que hace mediante el control remoto, tambin las podrs hacer si se levanta de la silla, va al televisor y presiona los botones correspondientes.(Alguna vez lo habr hecho!). La interfaz que el televisor le presenta (conjunto de botones y perillas) no es, obviamente, la misma que le muestra al control remoto (un receptor de rayos infrarrojos). La figura 2.7 le muestra esto. 2.12 ASOCIACIONES Otro acontecimiento comn es que los objetos se relacionan entre s de alguna forma. Por ejemplo, cuando enciende su televisor, en trminos de orientacin a objetos, usted se asocia con su televisor. La asociacin encendido es en una sola direccin (una va), esto es, usted enciende el televisor, como se ve en la figura 2.7. No obstante, a menos que vea demasiada televisin, ella no le devolver el favor. Hay otras asociaciones que son en dos direcciones, como casamiento.

30

Anlisis de Sistemas

Figura 2.7. Ejemplo de un mensaje enviado de un objeto a otro: el objeto control remoto enva un mensaje al objeto televisor para encenderse. El objeto televisor recibe el mensaje mediante su interfaz, un receptor infrarrojo.

Figura 2.8. Con frecuencias los objetos se relacionan entre s de alguna forma. Cuando usted enciende su televisor, tendr una asociacin en una sola direccin con l.

En ocasiones, un objeto podra asociarse con otro en ms de una forma. Si usted y su colaborador son amigos, ello servir de ejemplo. Usted tendra una asociacin es amigo de, as como es colaborador de, como se aprecia a continuacin Figura 2.9. En ocasiones, los objetos pueden asociarse en ms de una forma.

31

Anlisis de Sistemas

Una clase se puede asociar con ms de una clase distinta. Una persona puede viajar en automvil, pero tambin puede hacerlo en autobs. Figura 2.10. Una clase puede asociarse con ms de una clase distinta.

La multiplicidad (o diversificacin) es un importante aspecto de las asociaciones entre objetos. Indica la cantidad de objetos de una clase que se relacionan con otro objeto en particular de la clase asociada. Por ejemplo, en un curso escolar, el curso se imparte por un solo instructor, en consecuencia, el curso y el instructor estn en una asociacin de uno a uno. Sin embargo, en un seminario hay diversos instructores que impartirn el curso a lo largo del semestre, por lo tanto, el curso y el instructor tienen una asociacin de uno a muchos. Podr encontrar todo tipo de multiplicidades si echa una mirada a su alrededor. Una bicicleta rueda en dos neumticos (multiplicidad de uno a dos), un triciclo rueda en tres. 2.13 AGREGACIN Vea su computador: cuenta con un case o gabinete, un teclado, un ratn, un monitor, una unidad de Cd_Rom, uno o varios discos duros, una impresora y, posiblemente, parlantes. Dentro del case o gabinete, junto con las citadas unidades de disco duro, tienen una CPU, una tarjeta de video, una de sonido, y otros elementos sin los que, sin duda, difcilmente podra vivir.

Su computadora es una agregacin o adicin, otro tipo de asociacin entre objetos. Como muchas otras cosas que valdra la pena tener, su equipo est constituido de diversos tipos de componentes. Tal vez conozca varios tipos de agregaciones.

32

Anlisis de Sistemas

Figura 2.11. Una computadora es un ejemplo de agregacin: un objeto que se conforma de una combinacin de diversos tipos de objetos.

Un tipo de agregacin trae consigo una estrecha relacin entre un objeto agregado y sus objetos componentes. A esto se le conoce como composicin. El punto central de la composicin es que el componente se considera como tal solo como parte del objeto compuesto. Por ejemplo: una camisa est compuesta de cuerpo, cuello, mangas, botones, ojales y puos. Suprima la camisa y el cuello ser intil. En ocasiones un objeto compuesto no tiene el mismo tiempo de vida que sus propios componentes. Las hojas de un rbol pueden morir antes que el rbol. Si destruye al rbol, tambin las hojas morirn. La agregacin y la composicin son importantes dado que reflejan casos extremadamente comunes, y ello ayuda a que cree modelos que se asemejen considerablemente a la realidad.

33

Anlisis de Sistemas

Figura 2.12. En una composicin, un componente puede morir antes que el objeto compuesto. Si destruye al objeto compuesto, destruir tambin a los componentes.

2.14 LA RECOMPENSA Los objetos y sus asociaciones conforman la columna vertebral de la funcionalidad de los sistemas. Para moderarlos, necesitar comprender lo que son las asociaciones. Si est consciente de los posibles tipos de asociaciones. Tendr una amplia gama de posibilidades cuando hable de los clientes respecto a sus necesidades, obtendr sus requerimientos y crear los modelos de los sistemas que los ayudarn a cumplir con sus retos de negocios.

Lo importante es utilizar los conceptos de la orientacin a objetos para ayudarle a comprender el rea de conocimiento de su cliente (su dominio), y esclarecer sus puntos de vista al cliente en trminos que l o ella puedan comprender. Es all donde se aplica el UML. 2.15 RESUMEN La Orientacin a objetos es un paradigma que depende de algunos principios fundamentales. Un objeto es una instancia de una clase. Una Clase es una categora genrica de objetos que tienen los mismos atributos y acciones. Cuando

34

Anlisis de Sistemas

crea aun objeto, el rea del problema en que trabaje determinar cuntos de los atributos y acciones debe tomar en cuenta. La herencia es un aspecto importante de la orientacin a objetos, un objetos hereda los atributos y operaciones de su clase. Una tambin puede heredar atributos y acciones de otra. El Poliformismo es otro aspecto importante, ya que especifica que una accin puede tener el mismo nombre en diferentes clases y cada clase ejecutar tal operacin de forma distinta. Los objetos ocultan su funcionalidad de otros objetos y del mundo exterior. Cada objeto presenta una interfaz para que otros objetos (y personas) puedan aprovechar su funcionalidad. Los objetos funcionan en conjunto mediante el envo de mensajes entre ellos. Los mensajes son peticiones para realizar operaciones. Por lo general, los objetos se asocian entre s y esta asociacin puede ser de diversos tipos. Un objeto en una clase puede asociarse con cualquier cantidad de objetos distintos en otra clase. La Agregacin es un tipo de asociacin. Un objeto agregado consta de un conjunto de objetos que lo componen y una composicin es un tipo especial de agregacin. En un objeto compuesto, los componentes solo existen como parte del objeto compuesto. Preguntas P. Se dice que la orientacin a objetos a tomado por asalto al mundo del software. Qu no hay algunas aplicaciones importantes que no estn orientadas a objetos? .

35

Anlisis de Sistemas

UNIDAD III Introduccin a lenguaje de modelamiento unificado U.M.L.

3.- INTRODUCCION A UML Es un lenguaje grfico para visualizar, especificar, construir y documentar las partes de un sistema de software desde distintos puntos de vista. Ofrece una forma estndar de modelar sistemas software, pudiendo utilizarse: o Con cualquier proceso de desarrollo. o A lo largo de todo el ciclo de vida. o Con distintas tecnologas de implementacin Puede usarse tambin en otras reas, como la ingeniera de negocio, modelado de procesos, etc. Es un lenguaje de modelado que permite la representacin conceptual y fsica de un sistema. Bloques de construccin del lenguaje: Elementos Estructurales, comportamiento, agrupacin, anotacin Relaciones Dependencia, asociacin, generalizacin, realizacin Diagramas Clases, objetos, casos de uso, secuencia, colaboracin, Estados, actividades, componentes, despliegue. No es un mtodo, ni un proceso ni una metodologa. No establece qu modelos construir. Para un ptimo aprovechamiento, debe ser usado en un proceso: guiado por casos de uso,

36

Anlisis de Sistemas

UML es una familia de notaciones, tiles para describir distintos aspectos de un sistema: o Esttico. Describe los elementos del sistema y sus relaciones. o Dinmico. Describe el comportamiento del sistema a lo largo del tiempo. o Casos de Uso. Desde el punto de vista del usuario.

37

Anlisis de Sistemas

3.1 PORQU ES NECESARIO EL UML En los principio de la computacin, los programadores no realizaban anlisis muy profundos sobre el problema por resolver. Si acaso garabateaban algo en una servilleta. Con frecuencia comenzaban a escribir el programa desde el principio, y el cdigo necesario se escriba conforme se requera. Aunque anteriormente esto se agregaba un aurea de aventura y atrevimiento al proceso, en la actualidad es inapropiado en los negocios de alto riesgo. Hoy en da es necesario contar con un plan bien analizado. Un cliente tiene que comprender qu es lo que har un equipo de desarrolladores; adems tiene que ser capaz de sealar cambios si no se han captado claramente sus necesidades (o si cambia de opinin durante el proceso). A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que cada uno de sus miembros tiene que saber qu lugar toma su trabajo en la solucin final (as como saber cul es la solucin general). Conforme aumenta la complejidad del mundo, los sistemas informticos tambin debern crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que se comunican a grandes distancias mediante una red, misma que est vinculada a base de datos que, a su vez, contienen enormes cantidades de informacin. Si desea crear sistemas que lo involucren en este nuevo milenio cmo manejar tanta complejidad? La clave est en organizar el proceso del diseo de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con l. El UML proporciona tal organizacin. Un arquitecto no podra crear una compleja estructura como lo es un edificio de oficinas sin crear primero un anteproyecto detallado; as mismo usted tampoco podra generar un complejo sistema en un edificio de oficinas sin crear un plan de diseo detallado. La idea es que as como un arquitecto le muestra un anteproyecto a la persona que lo contrat, usted debera mostrarle un plan de diseo al cliente. Tal plan de diseo debe ser el resultado de un cuidadoso anlisis de las necesidades del cliente. Otra caracterstica del desarrollo de sistemas, es reducir el perodo de desarrollo. Cuando los plazos estn muy cerca uno del otro en absolutamente necesario contar con un plan slido. Hay otro aspecto de la vida moderna que demanda de un diseo slido: las adquisiciones corporativas. Cuando una empresa adquiere a otra, la nueva organizacin debe tener la posibilidad de modificar aspectos importantes de un

38

Anlisis de Sistemas

proyecto en desarrollo que est en progreso (la herramienta de desarrollo, el lenguaje de codificacin y otras ms). Un anteproyecto bien diseado facilitar la conversin. Si el diseo es slido, un cambio en la implementacin proceder sin problemas. La necesidad de diseos slidos ha trado consigo la creacin de una notacin de diseo que los analistas, desarrolladores y clientes acepten como pauta (tal como la notacin en los diagramas esquemticos sirve como pauta para los trabajadores de electrnica). El UML es la misma notacin. 3.2 LA CONCEPCIN DEL UML El UML es la creacin de Grady Booch, James Rumbaugh e Ivar Jacobson. Estos caballeros, apodados recientemente Los Tres Amigos, trabajan en empresas distintas durante la dcada de los aos ochenta y principios de los noventa y cada uno dise su propia metodologa para el anlisis y diseo orientado a objetos. Sus metodologas predominaron sobre la de sus competidores. A mediados de los noventa empezaron a intercambiar ideas entre s y decidieron desarrollar su trabajo en conjunto. El punto Orientacin de Objetos y Uso de Relaciones, tratan de la orientacin a objetos. Los conceptos de orientacin a objetos tienen un papel fundamental en el desarrollo de este texto.

En 1.994 Rumbaugh ingres a Rational Software Corporation, donde ya trabajaba Booch. Jacobson ingres a Rational un ao despus; el resto, como dicen, es historia. Los anteproyectos del UML empezaron a circular en la industria del software y las reacciones resultantes trajeron consigo considerables modificaciones. Conforme diversos corporativos vieron que el UML era til a sus propsitos, se conform un consorcio del UML. Entre los miembros se encuentran DEC, Hewlett Packard, Intellicorp, Microsoft, Oracle, Texas Instrument y Rational. En 1.997el consorcio produjo la versn 1.0 del UML y lo puso a consideracin del OMG (Grupo de administracin de objetos) como respuesta a una propuesta para un lenguaje de modelado estndar.

39

Anlisis de Sistemas

3.3 CONCEPTOS UML 3.3.1 CLASES Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Una clase implementa una o ms interfaces. Grficamente se representa como un rectngulo que incluye su nombre, sus atributos y sus operaciones. 3.3.2 ATRIBUTOS Un Atributo es una propiedad o caracterstica de una clase y describe un rango de valores que la propiedad podr contener en los objetos (esto es, instancias) de una clase, Una clase podr contener varios o ningn atributo. Por convencin, si el atributo consta de una sola palabra se escribe en minsculas; por otro lado, si el nombre contiene ms de una palabra, cada palabra ser unida a la anterior y comenzar con una letra mayscula, a excepcin de la primera palabra que comenzar en minscula. La lista de nombres de atributos iniciar luego de una lnea que la separe del nombre de la clase. Figura 3.1 Una clase y sus atributos

3.3.3 OPERACIONES

Una operacin es algo que la clase puede realizar, o que usted (u otra clase) pueden hacer a una clase. De la misma manera que el nombre de un atributo, el nombre de una operacin se escribe en minsculas si consta de una sola palabra. Si el nombre constara de ms de una palabra, nalas e inicie todas con mayscula. La lista de operaciones se inicia debajo de una lnea que separa a las operaciones de los atributos.

40

Anlisis de Sistemas

Figura 3.2 Las operaciones aparecen debajo de los atributos

3.3.4 CASOS DE USO Un caso de uso es la descripcin de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de inters para un actor particular. Un caso de uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es realizado por una colaboracin. Se representa con una elipse con borde continuo. El nombre miLavadoora: Lavadora es una instancia con nombre; pero tambin es posible tener una instancia annima, como: Lavadora.

3.4 DIAGRAMAS DEL UML El UML est compuesto por diversos elementos grficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. En lugar de indicarle a usted cules son los elementos y las reglas, veamos directamente los diagramas ya que los utilizar para hacer el anlisis y el sistema.

Este enfoque es similar a aprender un idioma extranjero mediante el uso del mismo, en lugar de aprender sus reglas gramaticales y la conjugacin de sus verbos. Despus de un tiempo de hablar otro idioma se le facilitar la conjugacin de verbos y la comprensin de las reglas gramaticales.

La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. El modelo UML de un sistema es similar a un modelo a escala de un edificio junto con la interpretacin del artista del edificio. Es

41

Anlisis de Sistemas

importante destacar que un modelo UML describe lo que supuestamente har un sistema, pero no dice cmo implementar dicho sistema. A continuacin se describirn brevemente los diagramas ms comunes del UML y los conceptos que representan. Posteriormente, se vern cada uno de los diagramas. Recuerde que es posible generar hbridos de estos diagramas y que el UML otorga formas de organizarlos y extenderlos. 3.4.1 DIAGRAMAS DE CLASES Piense en las cosas que le rodean (una idea demasiado amplia, pero intntelo de cualquier forma!). Es probable que muchas de esas cosas tengan atributos (propiedades) y que realicen determinadas acciones. Podramos imaginar cada una de esas acciones como un conjunto de tareas. Tambin se encontrar con que las cosas naturalmente se albergan en categoras (automviles, mobiliario, lavadoras). A tales categoras las llamaremos clases. Una clase es una categora o grupo de cosas que tienen atributos y acciones similares. He aqu un ejemplo: cualquier cosa dentro de la clase lavadoras tiene atributos como son la marca, el modelo, el nmero de serie y la capacidad. Entre las acciones de las cosas de esta clase se encuentran: agregar ropa, agregar detergente. activarse y sacar ropa. A continuacin se muestra un ejemplo de la notacin del UML que captura los atributos y acciones de una lavadora. Un rectngulo es el smbolo que representa a la clase, y se divide en tres reas. El rea superior contiene el nombre, el rea central contiene los atributos, y el rea inferior las acciones. Un diagrama de clases est formado por varios rectngulos de este tipo conectados por lneas que muestran la manera en que las clases se relacionan entre s.

Figura 3.3 El smbolo UML de una clase. Lavadora marca modelo nmero de serie capacidad agregar ropa() agregar detergente() sacar ropa()

42

Anlisis de Sistemas

Qu objetivo tiene pensar en las clases, as como sus atributos y acciones? Para interactuar con nuestro complejo mundo, la mayora del software moderno simula algn aspecto del mundo. Dcadas de experiencia sugieren que es ms sencillo desarrollar aplicaciones que simulen algn aspecto del mundo cuando el software representa clases de cosas reales. Los diagramas de clases facilitan las representaciones a partir de las cuales los desarrolladores podrn trabajar. A su vez, los diagramas de clases colaboran en lo referente al anlisis. Permiten al analista hablarle a los clientes en su propia terminologa, lo cual hace posible que los clientes indiquen importantes detalles de los problemas que requieren ser resueltos. Todo objeto de la clase tiene su valor especfico en cada atributo. En la siguiente figura observe que el nombre de un objeto inicia con una letra minscula, y est precedido de dos puntos que a su vez estn precedidos del nombre de la clase, y todo el nombre est subrayado. Figura 3.4 Un objeto cuenta con un valor especfico en cada uno de los atributos que lo componen.

El UML le da la opcin de indicar informacin adicional de los atributos. En el smbolo de la clase, podr especificar algn tipo para cada valor del atributo. Entre los posibles tipos se encuentran cadena (string), nmero de punto flotante (float), entero (integer) y booleano (boolean), as como otros tipos enumerados. Para indicar un tipo, utilice dos puntos (:) para separar el nombre del atributo de su tipo. Tambin podr indicar un valor predeterminado para un atributo. La siguiente figura muestra la forma de establecer atributos.

Aunque no parece haber restriccin en la designacin de tipos a las variables, utilizaremos los nombres en ingls para ceirnos a los tipos que aparecen en los lenguajes de programacin.

43

Anlisis de Sistemas

Figura 3.5 Un atributo puede mostrar su tipo as como su valor predeterminado.

Asi como es posible establecer informacin adicional de los atributos, tambin lo es en lo concerniente a las operaciones. En los parntesis que preceden al nombre de la operacin podr demostrar el parmetro con el que funcionar la operacin junto con su tipo de dato. La funcin, que es un tipo de operacin, devuelve un valor luego que finaliza su trabajo. En una funcin podr mostrar el tipo de valor que regresar.

Estas secciones de informacin acerca de una operacin se conocen como la firma de operacin. En la siguiente figura se muestra cmo representar la firma. Figura 3.6 La firma de una operacin

3.4.1.1 ATRIBUTOS, OPERACIONES Y CONCEPCIN Hasta ahora, hemos tratado a las clases como entidades aisladas, y hemos visto todos los atributos y operaciones de una clase. No obstante, en la prctica mostrar ms de una clase a la vez; cuando lo haga, no ser muy til que siempre aparezcan todos los atributos y operaciones, ya que el hacerlo le creara un diagrama muy saturado. En lugar de ello podr tan solo mostrar el nombre de la clase y dejar ya sea el rea de atributos o el de operaciones (o ambas) vaca, como se muestra a continuacin.

44

Anlisis de Sistemas

Figura 3.7

En ocasiones ser bueno mostrar algunos (pero no todos) de los atributos u operaciones. Para indicar que solo ensear algunos de ellos, seguir la lista de aquellos que mostrar con tres puntos (). A la omisin de ciertos o todos los tributos y operaciones se le conoce como abreviar una clase.

Figura 3.8.

Si hay una larga lista de atributos y operaciones podr utilizar un estereotipo para organizarla de forma que sea ms comprensible. Un estereotipo es el modo en que el UML le permite extenderlo, es decir, crear nuevos elementos que son especficos de un problema en particular que intente resolver. El estereotipo se muestra como un nombre bordeado por dos pares de parntesis angulares. Se los puede utilizar en una lista de atributos y operaciones. Figura 3.9

45

Anlisis de Sistemas

3.4.1.2 RESPONSABILIDADES Y RESTRINCCIONES El smbolo de clase le permite establecer otro tipo de informacin de s misma. En un rea bajo la lista de operaciones, podr mostrar la responsabilidad de la clase. La Responsabilidad es una descripcin de lo que har la clase, es decir, lo que sus atributos y operaciones intentan realizar en conjunto. Una lavadora por ejemplo, tiene la responsabilidad de recibir la ropa sucia y dar por resultado ropa limpia. Figura 3.10

La idea es incluir informacin suficiente para describir una clase de forma inequvoca. Una manera ms formal es agregar una restriccin, un texto libre bordeado por llaves; este texto especifica una o varias reglas que sigue la clase. Figura 3.11. La regla entre llaves restringe al atributo capacidad para contener uno de tres posibles valores.

46

Anlisis de Sistemas

3.4.2 DIAGRAMAS DE OBJETOS Un objeto es una distancia de clase (una entidad que tiene valores especficos de los atributos y acciones). Su lavadora, por ejemplo, podra tener la marca Laundatorium, el modelo Washmeister, el nmero de serie GL57774 y una capacidad de 7 Kg. La figura 1.2 le muestra la forma en que el UML, representa a un objeto. Vea que el smbolo es un rectngulo, como en una clase, pero el nombre est subrayado. El nombre de la instancia especfica se encuentra a la izquierda de los dos puntos (:), y el nombre de la clase a la derecha. Figura 3.12 El smbolo UML del objeto Mi Lavadora: Lavadora

3.4.3 DIAGRAMA DE CASOS DE USO Un caso de uso es una descripcin de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, sta es una herramienta valiosa, ya que es una tcnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que pueda ser utilizado por la gente en general (no slo por expertos en computacin). Posteriormente trataremos este tema con mayor detalle; por ahora, le mostrar un ejemplo sencillo. Usted utiliza una lavadora, obviamente, para lavar su ropa. La figura 1.3 le muestra cmo representara esto en un diagrama de casos de uso UML. Figura 3.13 Diagramas de casos de uso UML

47

Anlisis de Sistemas

A la figura correspondiente al Usuario de la lavadora se le conoce como actor. La elipse representa el caso de uso. Vea que el actor (la entidad que inicia el caso de uso) puede ser una persona u otro sistema. 3.4.4 DIAGRAMA DE ESTADOS En cualquier momento, un objeto se encuentra en un estado en particular. Una persona puede ser recin nacida, infante, adolescente, joven o adulta. Un elevador se mover hacia arriba, estar un estado de reposo o se mover hacia abajo. Una lavadora podr estar en la fase de remojo, lavado, enjuague, centrifugado o apagada. El diagrama de estados UML, que aparece en la figura 1.4, captura esta pequea realidad. La figura muestra las transiciones de la lavadora de un estado al otro. El smbolo que est en la parte superior de la figura representa el estado inicial y el de la parte inferior el estado final. Figura 3.14 Diagramas de estado UML

3.4.5 DIAGRAMA DE SECUENCIA Los diagramas de clases y los de objeto representan informacin esttica. No obstante, en un sistema funcional los objetos interactan entre s, y tales interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la mecnica de la interaccin con base en tiempos.

48

Anlisis de Sistemas

Continuando con el ejemplo de la lavadora, entre los componentes de la lavadora se encuentran: una manguera de agua (para obtener agua fresca), un tambor (donde se coloca la ropa) y un sistema de drenaje. Por supuesto, estos tambin son objetos (como ver, un objeto puede estar conformado por otros objetos). Qu suceder cuando invoque al caso de uso lavar ropa? Si damos por hecho que complet las operaciones agregar ropa, agregar detergente y activar, la secuencia sera ms o menos as: 1. El agua empezar a llenar el tambor mediante una manguera. 2. El tambor permanecer inactivo durante cinco minutos. 3. La manguera dejar de abastecer agua. 4. El tambor girar de un lado a otro durante quince minutos. 5. El agua jabonosa saldr por el drenaje. 6. Comenzar nuevamente el abastecimiento de agua. 7. El tambor continuar girando. 8. El abastecimiento de agua se detendr. 9. El agua del enjuague saldr por el drenaje. 10.El tambor girar en una sola direccin y se incrementar su velocidad por cinco minutos. 11.El tambor dejar de girar y el proceso de lavado habr finalizado.

La figura 3.15 presenta un diagrama de secuencias que captura las interacciones que se realizan a travs del tiempo entre el abastecimiento de agua, el tambor y el drenaje (representados como rectngulos en la parte superior del diagrama). En este diagrama el tiempo se da de arriba hacia abajo.

49

Anlisis de Sistemas

Figura 3.15 Diagramas de secuencias UML

Por cierto, volviendo a las ideas acerca de los estados, podramos caracterizar los pasos 1 y 2 como el estado de remojo, 3 y 4 como el estado de lavado, 5 a 7 como el estado de enjuague y del 8 al 10 como el estado de centrifugado. 3.4.6 DIAGRAMA DE ACTIVIDADES Las actividades que ocurren dentro de un caso de uso o dentro del comportamiento de un objeto se dan, normalmente, en secuencia, como en los once pasos de la

50

Anlisis de Sistemas

seccin anterior. La figura 3.16 muestra la forma en que el diagrama de actividades UML representa los pasos del 4 al 6 de tal secuencia.

Figura 3.16 Diagrama de Actividades UML.

3.4.7 DIAGRAMA DE COLABORACIONES

Los elementos de un sistema trabajan en conjunto para cumplir con los objetivos del sistema, y un lenguaje de modelado deber contar con una forma de representar esto. El diagrama de colaboraciones UML, diseado con este fin, se muestra en la figura 3.17. Este ejemplo agrega un cronmetro interno al conjunto de clases que constituyen a una lavadora. Luego de cierto tiempo, el cronmetro detendr el flujo de agua y el tambor comenzar a girar de un lado a otro. Figura 3.17 Diagrama de colaboraciones UML

51

Anlisis de Sistemas

3.4.8 DIAGRAMA DE COMPONENTES Este diagrama y el siguiente dejarn el mundo de las lavadoras, dado que estn ntimamente ligados con los sistemas informticos. El moderno desarrollo de software se realiza mediante componentes, lo que es particularmente importante en los procesos de desarrollo en equipo. Sin extenderme mucho en este punto le mostrar, en la figura 3.18, la manera en que el UML representa un componente de software. Figura 3.18 Diagramas de componentes UML

3.4.9 DIAGRAMA DE DISTRIBUCIN El diagrama de distribucin UML muestra la arquitectura fsica de un sistema informtico. Puede representar los equipos y dispositivos, mostrar sus interconexiones y el software que se encontrar en cada mquina. Cada computadora est representada por un cubo y las interacciones entre las computadoras estn representadas por lneas que conectan a los cubos. La figura 3.19 presenta un ejemplo. Figura 3.19 Diagrama de distribucin UML

Otras caractersticas Anteriormente, mencion que el UML proporciona caractersticas que le permiten organizar y extender los diagramas. Paquetes

52

Anlisis de Sistemas

En algunas ocasiones se encontrar con la necesidad de organizar los elementos de un diagrama en un grupo. Tal vez quiera mostrar que ciertas clases o componentes son parte de un subsistema en particular. Para ello, los agrupar en un paquete, que se representar por una carpeta tabular, como se muestra en la figura 3.20.

Figura 3.20 El paquete UML le permite agrupar los elementos de un diagrama.

Notas Es frecuente que alguna parte del diagrama no presente una clara explicacin del porqu est all o la manera den que trabaja. Cuando ste sea el caso, la nota UML ser til. Imagine a una nota como el equivalente grfico de un papel adhesivo. La nota es un rectngulo con una esquina doblada, y dentro del rectngulo se coloca la explicacin. Usted adjunta la nota al elemento del diagrama conectndolos mediante una lnea discontinua. Figura 3.21 En cualquier diagrama, podr agregar comentarios aclaratorios mediante una nota.

Estereotipos

53

Anlisis de Sistemas

El UML otorga varios elementos de utilidad, pero no es un conjunto minucioso de ellos. De vez en cuando disear un sistema que requiera algunos elementos hechos a la medida. Los estereotipos o cliss le permiten tomar elementos propios del UML y convertirlos en otros. Es como comprar un traje del mostrador y modificarlo para que se ajuste a sus medidas (contrario a confeccionarse uno completamente nuevo). Imagine a un estereotipo como este tipo de alteracin. Lo representar como un nombre entre dos pares de parntesis angulares y despus los aplicar correctamente.

El concepto de una interfaz provee un buen ejemplo. Una interfaz es una clase que realiza operaciones y que no tiene atributos, es un conjunto de acciones que tal vez quiera utilizar una y otra vez en su modelo. En lugar de inventar un nuevo elemento para representar una interfaz, podr utilizar el smbolo de una clase con interfaz situada justo sobre el nombre de la clase, como se muestra en la figura 1.12. Figura 3.22 Un estereotipo le permite crear nuevos elementos a partir de otros existentes.

3.5 PARA QU TANTOS DIAGRAMAS Como puede ver, los diagramas del UML le permiten examinar un sistema desde distintos puntos de vista. Es importante recalcar que en un modelo UML no es necesario que aparezcan todos los diagramas. De hecho, la mayora de los modelos UML contienen un subconjunto de los diagramas que he indicado. Por qu es necesario contar con diferentes perspectivas de un sistema? Por lo general, un sistema cuenta con diversas personas implicadas las cuales tienen enfoques particulares en diversos aspectos del sistema. Volvamos al ejemplo de la lavadora. Si diseara el motor de una lavadora, tendra una perspectiva del sistema; si escribiera las instrucciones de operacin, tendra otra perspectiva. Si diseara la forma general de la lavadora vera al sistema desde una perspectiva distinta a si tan solo tratara de lavar su ropa.

54

Anlisis de Sistemas

El escrupuloso diseo de un sistema involucra todas las posibles perspectivas, y al diagrama UML le da una forma de incorporar una perspectiva en particular. El objetivo es satisfacer a cada persona implicada. 3.7 RESUMEN El desarrollo de sistemas es una actividad humana. Sin un sistema de notacin fcil de comprender, el proceso de desarrollo tiene una gran cantidad de errores. El UML es un sistema de notacin que se ha convertido en estndar en el mundo del desarrollo de sistemas. Es el resultado del trabajo hecho por Grady Booch, James Rumbaugh e Ivar Jacobson. El UML est constituido por un conjunto de diagramas, y proporciona un estndar que permite al analista de sistemas generar un anteproyecto de varias facetas que sean comprensibles para los clientes, desarrolladores y todos aquellos que estn involucrados en el proceso de desarrollo. Es necesario contar con todos esos diagramas dado que cada uno se dirige a cada tipo de persona implicada en el sistema. Un modelo UML indica qu es lo que supuestamente har el sistema, mas no cmo lo har. Preguntas P He visto que se refiere al Lenguaje Unificado de como UML y como el UML. Cul es el correcto? P Ha indicado que el UML es adecuado para los analistas. No obstante, el diagrama de distribucin no parece ser algo muy til en la fase de anlisis en el desarrollo de un sistema. No sera ms apropiado para una fase posterior? P Ha mencionado que es posible hacer diagramas hbridos. UML, perdn, el UML, impone limitaciones respecto a los elementos que podr combinar en un diagrama?