ensayo - 2e UTIM

PRESENTACION
NOMBRE DE LA ESCUELA: UNIVERSIDAD TECNOLOGICA DE IZUCAR DE
MATAMOROS
NOMBRE DEL PROFESOR: LIC CESAR ESPINOZA JIMENEZ
NOMBRE DE LA ALUMNA: MARIA LUISA HIDALGO CASTILLO
MATERIA: ANALISIS Y DISEÑO DE SOFTWERE
NO CONTROL: 10292075
TEMA: UML
ENSAYO
TEMA: UML
25/MARZO/2011
FUNDAMENTOS DE LA POO
Los primeros lenguajes de programación surgieron de la idea de Charles Babagge, la cual se le ocurrió a
este hombre a mediados del siglo XIX. Era un profesor matemático de la universidad de Cambridge e
inventor ingles, que la principio del siglo XIX predijo muchas de las teorías en que se basan los actuales
ordenadores. Consistía en lo que él denominaba la maquina analítica, pero que por motivos técnicos no
pudo construirse hasta mediados del siglo XX. Con él colaboro Ada Lovedby, la cual es considerada como
la primera programadora de la historia, pues realizo programas para aquélla supuesta maquina de
Babagge, en tarjetas perforadas. En 1823 el gobierno Británico lo apoyo para crear el proyecto de una
máquina de diferencias, un dispositivo mecánico para efectuar sumas repetidas. Pero Babagge se dedico
al proyecto de la máquina analítica, abandonando la máquina de diferencias, que se pudiera programar
con tarjetas perforadas, gracias a la creación de Charles Jacquard (francés). E
Construcción de un modelo mecánico de un sistema físico a partir de objetos concretos. Los
objetos aquí serían, en un modelo de una pista de carreras: los autos, las carreteras, las llegadas, las
graderías, espectadores, etc. En un modelo de un sistema planetario, tenemos los objetos concretos: los
planetas, los órbitas, el sol, la energía, etc.
Construcción de un modelo algorítmico de un sistema físico a partir de objetos de software. Los
objetos aquí serían: rutinas de conexión a DB, shorts, validación de acceso, despliegue, impresiones, etc.
Este concepto de POO se puede ver como una intuitiva correspondencia entre un software de simulación
de un sistema físico y el sistema físico en sí (o su modelo mecánico).
Modelo algorítmico: Análisis, diseño e implementación de un software usando objetos de “software”.
Objetos de software: Componentes que integran o conforman el modelo; pueden ser unidades de código
para resolver situaciones específicas, shorts, uso de DB, prints, funciones, vectores, etc.
Modelo mecánico: Análisis, diseño e implementación de prototipo a escala de un sistema físico usando
objetos concretos.
Objetos concretos: Partes físicas del modelo mecánico, ojo del modelo, no del sistema real; o sea, los
objetos planeta no son los planetas reales.
ANALISIS Y DISEÑO DE SOFTWERE | ¡Error! No hay texto con el estilo 1
especificado en el documento.
Modelo: Es una vista de un sistema del mundo real, es decir, una abstracción de dicho sistema
considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema
que son relevantes al propósito del modelo y a un apropiado nivel de detalle.
Diagrama: Representación gráfica de un modelo.
Abstracción: Capacidad del ser humano para entender una situación excluyendo detalles y sólo viéndola
a alto nivel. El hombre ha comprendido el mundo con la abstracción. Esta propiedad permite distinguir a
un objeto de los demás, observando sus características y comportamientos, pensando en qué es y no en
cómo se codificaría en un lenguaje. Con la abstracción se destaca lo importante y se ignora lo irrelevante,
o sea, hay ocultamiento de información. Hay abstracción de datos al declarar una variable tipo integer, ya
que internamente el compilador lo implementa en 2 bytes, lo cual es transparente al programador, o al
declarar una variable date, el compilador controla los días de los meses, acepta sólo operaciones válidas
entre las fechas, permitiendo al programador abstraerse de esos detalles. Estos tipos de datos abstractos
coleccionan valores y operaciones, los cuales se usan transparentemente sin importar su implementación:
otro lo implementa y yo lo uso.
Encapsulación de información: Ocultamiento de información, datos o funciones especiales a los
usuarios. En el caso de la programación, el encapsulamiento es lo que permite que tanto la estructura
(campos) como el comportamiento (métodos) se encuentren dentro del mismo cuerpo de código de la
clase con la que se crean los objetos. Dentro de la clase se deben agrupar tanto la información o datos de
los campos como las operaciones o métodos o funciones que operan sobre esta información.
Herencia: Propiedad que permite a los objetos ser construidos a partir de otros; es recibir de un módulo
superior sus características, tales como atributos o funciones (campos y métodos o comportamientos),
para usarlos en el módulo actual. Heredar es compartir atributos.
Sobre escritura (override): Posibilidad de heredar un método de un módulo y cambiarle el
comportamiento en el heredero, con la opción de poder usar el original, si se desea.
Métodos unidos a los objetos: los métodos de un objeto son inseparables y siempre formarán parte de
su cuerpo, como un todo.
Noción de self: unicidad de los objetos; son únicos y no se repiten, aunque sean de la misma clase. Así
como se puede definir varias variables del tipo INT cada una de las cuales es única, se puede crear o
instanciar varios objetos de una misma clase.
DIAGRAMA DE CLASES:
A partir del año 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh (creador de
OMT) se unen en una empresa común, Rational Software Corporation, y comienzan a unificar sus dos
métodos. Un año más tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que
se considera como la primera versión del UML. A finales de ese mismo año, Ivan Jacobson, creador de
OOSE (Object Oriented Software Engineer) se añade al grupo. Cómo objetivos principales de la
consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus
protagonistas se propusieron lo siguiente:
El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales
de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).
Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
Manejar los problemas típicos de los sistemas complejos de misión crítica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más
utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre
diferentes tipos de sistemas (no sólo software, sino también en el ámbito de los negocios), al aclarar las
ANALISIS Y DISEÑO DE SOFTWERE | ¡Error! No hay texto con el estilo 2
especificado en el documento.
fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos
de la OO.
Un diagrama
de
clases es
un
tipo
de
diagrama
estático
que
describe
la
estructura
de
un sistemamostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son
utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de
la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y
la relación entre uno y otro.
Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un
dominio - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos
Propiedades también llamados atributos o características, son valores que corresponden a un objeto,
como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del
objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso.

Operaciones comúnmente llamados métodos, son aquellas actividades o verbos que se pueden
realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la
misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas
si consta de una sola palabra Interfaz es un conjunto de operaciones que permiten a un objeto
comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto.

Herencia se define como la reutilización de un objeto padre ya definido para poder extender la
funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de
un objeto padre. Por ejemplo: Una persona puede especializarse en Proveedores, Acreedores,
Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además
cada uno tendrá información adicional que depende del tipo de persona, como saldo del cliente, total
de inversión del accionista, salario del empleado, etc.
Ejemplo 1: Una persona tiene número de documento de identificación, nombres, apellidos, fecha de
nacimiento, género, dirección postal, posiblemente también tenga número de teléfono de casa, del móvil,
FAX y correo electrónico.
Ejemplo 2: Un sistema informático puede permitir administrar la cuenta bancaria de una persona, por lo
que tendrá un número de cuenta, número de identificación del propietario de la cuenta, saldo actual,
moneda en la que se maneja la cuenta.
Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dónde las operaciones bancarias de una cuenta
(como en el ejemplo 2) se manejarán realizando diferentes operaciones que en el diagrama de clases de
balurdes sólo se representan como operaciones, que pueden ser: abrir, cerrar, depósito, retiro.
El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia
de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una
interfaz.
ANALISIS Y DISEÑO DE SOFTWERE | ¡Error! No hay texto con el estilo 3
especificado en el documento.
DIAGRAMA DE CASO DE USO:
James Rumbaugh había desarrollado su propia notación de diseño orientado a objetos llamada OMT
(Object Modeling Technique) en su libro "Object-Oriented Modeling and Design".
Por otro lado Jacobson se había revelado como un visionario del análisis (padre de los casos de uso) y
sobre todo del diseño orientado a objetos, sorprendiendo a todo el mundo en "Object-Oriented Software
Engineering: A Use Case Driven Approach". A mediados de los noventa empezaron a intercambiar
documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados
a objetos. En 1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después
Jacobson se unía a ellos en Rational.
En 1997 salió a la luz la versión 1.0 de UML. Casos de Uso no son parte del diseño (cómo), sino parte del
análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema
debe hacer. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir,
describen un uso del sistema y cómo este interactúa con el usuario. Si te has enfrentado alguna vez a
UML normalmente habrás visto algún diagrama de clases y esperarás que los Casos de Uso sean
también una forma visual de representar la información. Sin embargo estás muy equivocado, si bien los
casos de usos se pueden agrupar en diagramas, los diagramas no son lo importante. Voy a repetirlo para
que quede claro, "Los diagramas no son lo importante".
Sé que alguno estará impaciente con los diagramas, así que luego los trataré. Pero primero vayamos con
lo realmente interesante. Si lo primordial de los casos de uso (use case) no son los diagramas, entonces
¿que es lo importante? Lo realmente útil de los casos de uso es el documento que describe el caso de
uso (use case), en este documento se explica la forma de interactuar entre el sistema y el usuario.Pero lo
más claro es que te presente uno. Este podría ser el caso de uso (use case) de escribir un mensaje en un
foro.
ANALISIS Y DISEÑO DE SOFTWERE | ¡Error! No hay texto con el estilo 4
especificado en el documento.
Nombre:
Crear mensaje foro
Autor:
Joaquín Gracia
Fecha:
24/08/2003
Descripción:
Permite crear un mensaje en el foro de discusión.
Actores:
Usuario de Internet logeado.
Precondiciones:
El usuario debe haberse logeado en el sistema.
Flujo Normal:
1.
2.
3.
4.
El actor pulsa sobre el botón para crear un nuevo mensaje.
El sistema muestra una caja de texto para introducir el título del mensaje y una zona de mayor
tamaño para introducir el cuerpo del mensaje.
El actor introduce el título del mensaje y el cuerpo del mismo.
El sistema comprueba la validez de los datos y los almacena.
Flujo Alternativo:
4.
El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de
ello permitiéndole que los corrija
Poscondiciones:
El mensaje ha sido almacenado en el sistema.
REFERENCIAS:
EL LENGUAJE UNIFICADO MODELADO
AUTOR: GRADY BOOCH - JAMES RUMBAUGH- IVAR JACOBSON
CAPITULOVIII- XVII
FUNDAMENTOS DE JAVA –TERCERA EDICCION
AUTOR: HERBET SCHILDT PAG.8
JAVA 2 VERSION 1.4
AUTOR: ISRAEL PASTRANA VICENTE PAG: 31-33
ANALISIS Y DISEÑO DE SOFTWERE | ¡Error! No hay texto con el estilo 5
especificado en el documento.
ANALISIS Y DISEÑO DE SOFTWERE | ¡Error! No hay texto con el estilo 6
especificado en el documento.