capitulo ii uml

Ingeniería De Software I VI Ciclo

2.1 METODOLOGÍAS DE DESARROLLO ORIENTADO A OBJETOS

Las metodologías orientadas a objetos, surgieron a razón de problemas que se presentaban en las de tipo estructurado, tales como:

Generación de extensivas líneas de código, lo cual incrementaba el costo de fabricación del Software.

No se podía reutilizar el código. No daba facilidad al mantenimiento del sistema. Cuando se modificaba los componentes en el sistema, se

afectaban los demás componentes del mismo, creando un gran problema.

Como respuesta a estos problemas, se desarrolló las metodologías orientadas a objetos. En estas metodologías se cobra mucho más importancia el aspecto de "modelado" del sistema, examinando el dominio del problema como un conjunto de objetos que interactúan entres sí.

Existen muchas metodologías tales como: OMT, RUP, OBJECTORY, FUSION, GRAPPLE, XP, MSF, usando la notación UML del cual hablaremos mas adelante. Se dice que las metodologías más importantes son:

o La Metodología RUP es más adaptable para proyectos de largo plazo.

o La Metodología XP en cambio, se recomienda para proyectos de corto plazo.

o La Metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología.

2.2 INTRODUCCIÓN A UML

2.2.1 PARADIGMA BASADO EN OBJETOS

La programación estructurada era la corriente principal en los días más tempranos del software. Los diseñadores de programas empezaron desarrollando bloques normales de código para los procedimiento y luego copiaban ese código en cada aplicación. Si bien esto redujo el tiempo de desarrollo para las nuevas aplicaciones, era difícil realizar un cambio en un bloque de código, porque el diseñador tenía que hacer el cambio en todas aquellas partes donde ese código había sido

Capítulo II Metodologías OO -UML

11


copiado. La programación estructurada presento entonces algunos desafíos que la programación orientada a objetos fue diseñada para resolver.

Con la programación basada en objetos, los diseñadores crean bloques de código. Los llamados Objetos. Estos objetos se usan para varias aplicaciones. Si uno de los objetos requiere de una modificación, el diseñador necesita hacer el cambio una sola vez. Esta sola característica redujo considerablemente los costos, en la fabricación de software, Es por ello que en la actualidad las compañías están apresurándose en adoptar esa tecnología para ser integradas en sus aplicaciones existentes. De hecho la mayoría de aplicaciones que se desarrollan hoy en día, son basadas en objetos. Algunos lenguajes como java, por ejemplo requieren de una estructura basada en objetos.

El paradigma basado en objetos es una manera diferente de ver las aplicaciones. Con este enfoque, usted divide una aplicación en muchos fragmentos cortos y pequeños u objetos, que son entre si bastante independientes.

2.2.2CONCEPTOS Y PRINCIPIOS DE ORIENTACIÓN A

OBJETOS

A. OBJETOS: es la representación de una entidad sea real o conceptual. Un objeto puede representar algo concreto (una persona, un auto, una computadora, etc.), o un concepto (un proceso químico, una transacción bancaria, una orden de compra, etc.). Un objeto tiene tres características:

a. Estado: Representado por una colección de propiedades o atributos, por ejemplo el objeto Curso puede estar en uno de dos estados: “Abierto” o “Cerrado”.

b. Conducta: Representa todo lo que el objeto puede hacer (Operaciones), por ejemplo un curso disponible podría tener las operaciones: AgregarEstudiante() y EliminarEstudiante()

c. Identidad: Representa la unicidad de un objeto con respecto a otros objetos, por ejemplo: Matemática 001-Sección 1 y Matemática 001 Sección 2 son dos objetos del Sistema de Registro


12


Curso. Aunque ambos cursos están disponibles, cada uno tiene una única identidad.

En UML, los objetos son representados con rectángulos y el nombre del objeto es subrayado:

B. CLASES: es una descripción de un grupo de objetos la cual consta de: propiedades comunes (los atributos), conductas comunes(los funcionamientos), relaciones comunes y semántica común. Así una clase es una plantilla para crear objetos. Cada objeto es una instancia de alguna clase u objeto. Por ejemplo, la clase “Curso Disponible” puede definirse con las siguientes características:

i. Atributos: ubicación, horas disponibles.ii. Operaciones: recuperar ubicación, recuperar

horas al día, agregar estudiante.

Así: Matemática 001 – Sección 1 y Matemática 001 – Sección 2 son objetos pertenecientes a la clase “Curso Disponible”. Cada objeto debería tener valores para sus atributos y acceso a las operaciones especificadas en la clase “Curso Disponible”.

En UML, las clases se representan con rectángulos divididos en tres partes.

C. ENCAPSULACIÓN: en los sistemas basados en objetos, la combinación y empaquetamiento de fragmentos de información y conducta específica en un objeto se llama encapsulación.


13


Los objetos encapsulan sus operaciones y su estado, son islas de estado y comportamiento.

1. El comportamiento del objeto está definido por las operaciones.

2. El estado está definido por los datos o atributos del objeto .

La Encapsulación es un concepto de orientación a objetos que describe la vinculación de unas operaciones y estado a un objeto particular. La encapsulación está íntimamente relacionada con la ocultación de la información, definiendo qué partes de un objeto son visibles y qué partes están ocultas.

La encapsulación abarca a la ocultación de la información:

Algunas partes son visibles (el interfaz público) Otras partes son ocultas (o privadas)

Ejemplo: “El volante de un auto”, El volante es una interfaz pública hacia el mecanismo de giro de un coche, la implementación del coche es privada y sobre ella solo puede actuar el propio volante.

D. Herencia: es un mecanismo que le permite crear nuevos objetos basados en otros creados con anterioridad como por ejemplo: un niño hereda las características de un objeto padre.

Uno de los mayores beneficios de la herencia es la facilidad de mantenimiento. Por ejemplo: cuando algunos cambios afectan a todos los mamíferos, solo se efectuara el cambio en el objeto padre y los objetos hijo heredaran los cambios automáticamente. Si los mamíferos de repente se convirtieran en seres de sangre fría, solo el objeto mamífero necesitaría ser modificado. El gato, perro, humano, ballena, y otros hijos heredaran automáticamente la característica de seres de sangre fría.


14


E. POLIMORFISMO: significa tener muchas formas o aplicaciones de una funcionalidad particular. Como con la herencia, el polimorfismo puede verse en el mundo natural. Ejemplo dada la orden o función “Hable()”, un humano puede contestar “Como esta usted”, un perro puede contestar “ladrando”, un gato puede contestar “maullado” o probablemente el mensaje sea ignorado.

En condiciones de un sistema basado en objetos, esto significa que nosotros podemos tener muchas aplicaciones de una funcionalidad particular.

Por ejemplo, podríamos estar construyendo un sistema de dibujos gráficos. Cuando el usuario quiere dibujar algo, sea una línea, un circulo o rectángulo, el sistema emite una orden de dibujo. El sistema esta compuesto por muchos tipos de formas cada uno de los cuales contienen la conducta respectiva de dibujo. Así, cuando el usuario quiere dibujar un circulo, el objeto circulo dibuja la orden que es invocada. Usando el polimorfismo, el sistema deduce como se esta ejecutando y que tipo de forma esta siendo trazada.

2.3 PRINCIPIOS DE UML

Siglas de Unified Modeling Language(Lenguaje Unificado de Construcción de modelos).


15


UML es el resultado de los estudios de parte de Grady Booch, James Rumbaugh e Ivar Jacobson, estos señores apodados como los “tres amigos”, cada uno de ellos en los años ochenta trabajaron en empresas distintas con sus propias metodologías de análisis orientada a objetos, predominando entre sus competidores; sin embargo a mediados de los años noventa empezaron a intercambian ideas y emprendieron lo que es hoy el UML. Fueron también los creadores de Rational Software Corporation.Después de tantas discusiones fue presentado el proyecto de UML al OMG (grupo de Administración de Objetos) quienes adoptaron a UML como estándar en la industria del software y continua evolucionando.

2.3.1SIMBOLOGÍA

2.3.1.1 PAQUETES

Permiten dividir un modelo, reagrupar y encapsular los elementos de modelado y se representa con una carpeta con nombre.

Gráficamente un paquete viene representado como se indica en la Figura:

Cualquier sistema grande se debe dividir en unidades más pequeñas, de modo que las personas puedan trabajar con una cantidad de información limitada, a la vez y de modo que los equipos de trabajo no interfieran con el trabajo de los otros.


16


Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Los paquetes son unidades de organización jerárquica de uso general de los modelos de UML. Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión de la configuración y la construcción de bibliotecas que contengan fragmentos reutilizables del modelo.

2.3.1.2 CASOS DE USO

Un Caso de Uso es representado por una elipse y es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica.

Representan la funcionalidad del sistema y los requisitos del sistema desde la perspectiva del usuario.

Los objetivos de los casos de uso son los siguientes:

Capturar los requisitos funcionales del sistema y expresarlos desde el punto de vista del usuario.


17


Guiar todo el proceso de desarrollo del sistema de información.

Los casos de uso proporcionan, por tanto, un modo claro y preciso de comunicación entre cliente y desarrollador. Desde el punto de vista del cliente proporcionan una visión de “caja negra” del sistema, esto es, cómo aparece el sistema desde el exterior sin necesidad de entrar en los detalles de su construcción. Para los desarrolladores, suponen el punto de partida y el eje sobre el que se apoya todo el desarrollo del sistema en sus procesos de análisis y diseño.

2.3.1.3 ACTORES

Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Se representa mediante una figura humana dibujada con palotes.

Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.).

Si se habla de usuarios, un actor es el papel que puede llevar a cabo en cuanto a su forma de interactuar con el sistema, es decir, un único actor puede representar a muchos usuarios diferentes y de la misma forma, un usuario puede actuar como actores diferentes.

2.3.1.4 RELACIONES

Las relaciones pueden tener lugar entre actores y casos de uso o entre casos de uso.

La relación entre un actor y un caso de uso es una relación de comunicación, que indica que un actor interviene en el caso de uso. Normalmente, el actor aporta información para la realización de un caso de uso o recibe información como resultado de la realización del mismo, por ello, esta relación


18


puede ser unidireccional o bidireccional, aunque generalmente se muestra como bidireccional, ya que no es necesario especificar en detalle estas relaciones.

La relación entre casos de uso es una relación unidireccional. Esta relación puede presentar uno de los dos siguientes tipos: “usa” y “extiende”.

A. LA RELACIÓN “INCLUDE” (INCLUYE). Una instancia del Caso de uso origen incluye también el comportamiento descrito por el Caso de Uso destino. «include» reemplazó al denominado «uses», por ejemplo: si un actor realiza una interacción con un caso de uso A, automáticamente lo hará con el caso de uso B.

B. LA RELACIÓN “EXTEND” (EXTIENDE). Se utiliza cuando se quiere reflejar un comportamiento opcional de un caso de uso. Por ejemplo, se tiene el caso de uso A que representa un comportamiento habitual del sistema. Sin embargo, dependiendo de algún factor, este caso de uso puede presentar un comportamiento adicional o ligeramente diferente, que se podría reflejar en un caso de uso B. En este caso, habrá una relación “extiende” del caso de uso B al A.


19


2.3.2DIAGRAMAS DE UML

UML permite a las personas desarrollar diferentes tipos de diagramas visuales que representan varios aspectos de los sistemas, cada diagrama tiene un propósito y una intencionalidad. Object Domain apoya el desarrollo de la mayoría, de tales como:

2.3.2.1 DIAGRAMA DE CASO DE USO DEL NEGOCIO

Los diagramas de Caso de Uso de negocio se usan para representar la funcionalidad proporcionada en conjunto por una organización. Durante esta etapa, se contestan preguntas como: ¿Qué hace el negocio? O ¿Por qué estamos construyendo el sistema?

Estos diagramas se usan extensivamente durante las actividades de modelado del negocio, no solo


20


para analizar el contexto del sistema sino también para fundamentar el por que de la creación de los casos de uso. Estos diagramas no diferencian entre los procesos manuales y automatizados; mientras que los Diagramas de Caso de Uso si se enfocan en los procesos automatizados.

2.3.2.2 DIAGRAMA DE CASOS DE USO

Un diagrama de Casos de Uso muestra las distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones).

Los diagramas de caso de uso hacen que se muestren las interacciones entre los casos de uso y los actores.

Se muestra como ilustración los casos de uso de la máquina de café.


21


2.3.2.3 DIAGRAMA DE ACTIVIDADES

Los diagramas de actividad ilustran el flujo de funcionalidad en un sistema. Estos diagramas definen donde empieza y donde acaba el flujo del negocio y así conocer que actividades ocurren durante el flujo y en que orden ocurren. Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos. Generalmente modelan los pasos de un algoritmo.

Lo principales elementos que debe tener en cuenta conforme avance a través de un flujo de trabajo:

- Las actividades son representadas por rectángulos redondeados.

- Hay un estado de arranque o “star state” que representa el inicio del flujo de trabajo y un estado “end state” que representa el final del flujo de trabajo.

- Los puntos de decisión son representados por rombos.


22


2.3.2.4 DIAGRAMA DE SECUENCIAS

Los diagramas de secuencia se usan para mostrar el flujo de la funcionalidad a través de un caso de uso

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo. Esta descripción es importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación.


23


2.3.2.5 DIAGRAMA DE COLABORACIÓN

Un diagrama de colaboración es una forma de representar interacción entre objetos. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales,...) y ciclos en la ejecución.

2.3.2.6 DIAGRAMA DE CLASES


24


El diagrama de clases recoge las clases de objetos y sus asociaciones. En este diagrama se representa la estructura y el comportamiento de cada uno de los objetos del sistema y sus relaciones con los demás objetos, pero no muestra información temporal.

2.3.2.7 DIAGRAMA DE ESTADOS

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro. Mientras el diagrama de clases muestra un cuadro estático de las clases y sus relaciones, lo diagramas de estado se usan para modelar la conducta dinámica del sistema.


25


En un diagrama de estado encontramos dos estados especiales, el estado de arranque “Start” y el estado de parada “Stop”. El estado de arranque es representado por un punto negro, e indica el estado del objeto cuando es creado por primera vez. El estado de parada es representada por un punto negro encerrado en un circulo, y muestra el estado del objeto justo antes de que se destruya.

2.3.2.8 DIAGRAMA DE COMPONENTES

El diagrama de componentes proporciona una visión física del modelo, Muestra la organización de los componentes software, sus interfaces y las dependencias entre ellos. Hay dos tipos de componentes en el diagrama: los componentes ejecutables y las bibliotecas de código

Un componente es un módulo de software que puede ser código fuente, código binario, un ejecutable, o una librería con una interfaz definida. Una interfaz establece las operaciones externas de un componente, las cuales determinan una parte del comportamiento del mismo. Además se representan las dependencias entre componentes o entre un componente y la interfaz de otro, es decir uno de ellos usa los servicios o facilidades del otro.


26


2.3.2.9 DIAGRAMA DE DESPLIEGUE

El objetivo de estos diagramas es mostrar la disposición de las particiones físicas del sistema de información y la asignación de los componentes software a estas particiones. Es decir, las relaciones físicas entre los componentes software y hardware en el sistema a entregar.


27


Ejemplo:

El diagrama representa una arquitectura compuesta por un servidor central de lógica de negocio y acceso a datos, en un monitor de teleproceso de tipo XXX, al cual hay conectados 10 servidores departamentales, con clientes (100) e impresora conectados a cada uno de ellos. No interesa tanto recoger en el diagrama la infraestructura real (la exactitud de la configuración, número de procesadores que pueden cambiar con el tiempo y en principio no afecta ni al diseño ni a la construcción), como el tipo


28


“genérico” de los servidores, los volúmenes en el caso de que sean significativos (por ejemplo: 100 puestos por departamento).


29

capitulo ii uml

Documents