UNIDAD 2: Abstracción del Mundo real Al Paradigma ...

Programación II UML Dr. Mario Rossainz López

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

2.1. Principios básicos del Modelado de Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven un determinado problema, requieren ser automatizados. Como ejemplo podemos citar a toda aquella empresa o negocio de ventas donde el proceso consistente en que un cliente de dicha empresa llame por teléfono para solicitar la compra de un producto y éste le sea llegado por medio de un determinado medio de transporte; pueda ser automatizado. Si nosotros logramos de alguna forma la visualización de los componentes de dicho proceso así como de las relaciones de esta simple transacción, podremos entonces comprender el funcionamiento del proceso de una manera mucho más simple y sencilla que si lo describiéramos en palabras. El mapeo de los procesos del mundo real de un sistema software a una representación gráfica (blueprint) nos proporciona una visión más clara de ese sistema computarizado. A este mapeo se le conoce como el modelado visual. Son muchos los beneficios del modelado visual, entre ellos están:

La captura e identificación de procesos

Los enlaces de Comunicación

El manejo de la Complejidad

La definición de arquitecturas software

La reusabilidad disponible


2.1.1. CAPTURA DE PROCESOS En la actualidad los procesos computacionales engloban una gran variedad de procesos que se dan en las empresas o negocios. Es por eso que para entender un sistema software es necesario definir aquellos requerimientos inmersos en la operación de dichos procesos. Sin la definición de esos requerimientos el sistema o producto software no podrá construirse. Cuando se crean los casos de uso, el modelado visual que se define en esa parte captura los procesos de la empresa o negocio identificando los requerimientos del sistema software desde una perspectiva del usuario. Esto precisamente da pauta a la construcción del diseño y desarrollo de los procesos implicados. 2.1.2. COMUNICACIONES Los analistas y expertos en dominios son comúnmente quienes definen los requerimientos del sistema y las arquitecturas software. Por otro lado los desarrolladores son quienes construyen el sistema basándose en esos requerimientos. Estos dos grupos pueden y deben trabajar en equipo pero pueden existir diferencias, malos entendidos o desacuerdos entre ellos en la terminología que puedan emplear por separado. El modelado visual tiene una comunicación estándar y el UML en particular proporciona una suave transición entre el dominio del problema y el dominio de la computadora. Mediante la comunicación a través de un lenguaje común de modelado visual, todos los grupos y miembros de un equipo de trabajo, en particular basados en el diseño, operan y se comunican con la misma terminología minimizando así los desacuerdos o diferencias e incrementando la eficiencia.


2.1.3. MANEJO DE LA COMPLEJIDAD Es común que en empresas donde se realiza ingeniería de software los sistemas estén conformados de cientos de clases. Dichas clases se organizan entonces para ser vistas por muchos grupos diferentes de personas en base a las necesidades de cada uno de ellos con una visión por tanto diferente. El modelado visual proporciona la capacidad de mostrar elementos de modelado de varias formas de tal manera que dichos elementos pueden ser vistos en diferentes niveles de abstracción. Un mismo modelo puede tener varias vistas diferentes dependiendo de las necesidades o intereses del visor. 2.1.4. DEFINICION DE ARQUITECTURAS SOFTWARE El modelado visual proporciona la capacidad de capturar la arquitectura lógica del software independientemente del lenguaje de implementación que se quiera usar. En un sistema donde se diseñan procesos, el lenguaje de implementación es una herramienta determinada mientras que la arquitectura lógica de software es mapeada en una arquitectura física. Esta forma de mapeo proporciona una gran flexibilidad en el diseño de un producto software. Así por ejemplo si se decide cambiar la arquitectura del lenguaje C++ al lenguaje JAVA, con el modelado visual la arquitectura lógica es la misma y sólo necesita ser mapeada a la nueva implantación física.


2.1.5. REUSABILIDAD DISPONIBLE El modelado visual proporciona el uso de la reusabilidad de partes de un producto software o aplicación mediante la creación de componentes en el diseño del sistema. Estos componentes pueden ser compartidos y reutilizados por equipos de proyectos y los cambios pueden ser incorporados fácilmente dentro de aquellos proyectos existentes que están siendo desarrollados aun. La reusabilidad de componentes hace más flexibles los diseños. 2.1.6. QUE ES UML? Usando UML se puede llevar a cabo el modelado y obtener los beneficios enunciados en las secciones anteriores de éste capítulo. UML es el lenguaje estandar para la visualización, especificación, construcción y documentación de los artefactos o componentes de un producto o sistema software. Con UML:

Se incrementa la productividad de una empresa.

Se acorta el desarrollo de los ciclos de vida de un sistema software.

Se adquiere una alta calidad del software que se construye.


2.1.7. EVOLUCION DEL UML


2.2. MODELADO DE CLASES En esta sección se ilustra el modelado de los diagramas de clases para visualizar la estructura de un sistema software. 2.2.1. DIAGRAMAS DE CLASES La estructura de un sistema software surge cuando uno descubre los objetos que intervienen en dicho sistema. Un diagrama de clases ilustra las clases existentes dentro de un producto software así como las relaciones entre ellas. Por tanto, la naturaleza estática de un sistema se representa mediante los diagramas de clases. Las responsabilidades de los casos de uso se localizan en los objetos. La agrupación de dichos objetos en clases ayuda a manejar la complejidad de un sistema. Una clase por tanto, es una colección de objetos que comparten:

una estructura común

un comportamiento común

unas relaciones comunes

semánticas también comunes En nuestro ejemplo, en base al caso de uso “Crear un nuevo mercado o comercio” (Create New Trade) utilizamos objetos que forman parte de 5 clases: La clase Trade (Comercio o Mercado) La clase Trade Leg (Etapa de Comercio) La clase Trade Administrator (Administrador de Mercado o comercio) La clase Position Administrator (Posición del Administrador) La clase Slate (lista de candidatos)


2.2.2. ASOCIACIONES Las relaciones entre clases proporcionan un camino para la comunicación entre objetos. Una asociación es un tipo de relación. Las asociaciones entre clases son modeladas con líneas bidireccionales que establecen la relación entre clases. Los diagramas de secuencia y/o colaboración se examinan para determinar las ligas que puedan existir entre los objetos que se requieren existan para definir el comportamiento del sistema (por ejemplo, cuando dos objetos necesitan comunicarse, se puede establecer una liga entre ellos). 2.2.3. ROLES Uno de los propósitos de un diagrama de clases es la comunicación. Para ello es necesario añadir información a una relación de asociación. El establecimiento de comunicación en una relación es un role. Un role describe el propósito o capacidad para que una clase se pueda asociar con otra. El nombre de un role se coloca generalmente a lo largo de la línea de asociación que lo define. En el ejemplo del sistema comercial, la clase Trade Administrator (Administrador de mercado o comercio) juega el role de manager en la asociación con la clase Trade (Comercio o Mercado).


2.2.4. AGREGACIONES Una agregación es una forma especial de asociación. Las agregaciones ilustran la relación que hay entre un todo y sus partes. Siguiendo con el ejemplo, La clase Trade Leg (Etapa de Comercio) es una parte de la clase Trade (Comercio o Mercado). Esta asociación a final de cuentas es una agregación. 2.2.5. MULTIPLICIDAD Una vez establecidas las relaciones de asociación y agregación, será necesario conocer cuantos (muchos, varios, uno, etc.) objetos pueden participar en dichas relaciones. La multiplicidad es el número de instancias de una clase que están relacionadas con una instancia de la otra clase de la relación que se define. Para cada asociación y agregación, existe una multiplicidad formada por dos partes: una para cada extremo de la relación que se define. Por ejemplo: En el sistema del comercio, un objeto de la clase Trade Administrator (Administrador de Mercado o Comercio) se relaciona con cero o más objetos de la clase Trade (Comercio o Mercado); y un objeto de la clase Trade es asociado con exactamente un objeto de la clase Trade Administrator (Administrador de Mercado o Comercio). Similarmente un objeto Trade se compone de uno o más objetos Trade Leg y un objeto Trade Leg es parte de exactamente un objeto Trade.


2.2.6. NAVEGACIÓN Las asociaciones y agregaciones son bidireccionales por default, pero puede ser deseable restringir la navegación o flujo en una sola dirección. Si la navegación se restringe entonces será necesario añadir al esquema gráfico una flecha que indique la dirección de dicha navegación donde corresponda. En nuestro ejemplo, un Trade puede llamar a un Trade Leg pero no a la inversa.


2.2.7. ESTRUCTURA Y COMPORTAMIENTO Los diagramas de clase representan la estructura y comportamiento de cada clase que los conforman. La estructura de una clase es descrita mediante un conjunto de atributos. Un atributo es una definición de dato a través de un campo o variable que es utilizada a través de instancias de clases. Estos atributos son definidos en el segundo compartimiento de la representación gráfica de una clase en el diagrama de clases. Por otro lado, el comportamiento de una clase es representado por sus operaciones. Una operación es un servicio que puede ser utilizado por un objeto afectando su comportamiento. Las operaciones son descritas en el tercer compartimiento de la representación gráfica de una clase en el diagrama de clases . En el ejemplo que hemos estado siguiendo, cada objeto Trade tiene un atributo llamado Trader y una operación llamada constructLeg. 2.2.8. HERENCIA La herencia es otro tipo de relación. La herencia define una relación de clases donde una clase determinada comparte la estructura y/o comportamiento de una o más clases distintas. Esta relación define una jerarquía de abstracciones en donde una subclase hereda de una o más superclases. En el ejemplo del sistema comercial un objeto Trade Administrator y un objeto Position Administrator heredan de la clase Administrator. Esta relación por una parte define una estructura común para estos objetos: comportamiento y/o relaciones de nivel Administrator y por la otra define elementos únicos propios de la clase Trade Administrator y de la clase Position Administrator. Con todos estos conceptos vistos podemos entonces visualizar la estructura de la solución de un problema automatizado en un sistema software.

UNIDAD 2: Abstracción del Mundo real Al Paradigma ...

Documents

Transcript of UNIDAD 2: Abstracción del Mundo real Al Paradigma ...