04 PD DS Doo PDF

Anlisis y diseo orientado a objetos
Programa desarrollado

Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 1

CARRERA: Ingeniera en Desarrollo de Software
Cuatrimestre 04

Programa de la asignatura:

Clave: 160920413 / 150920413


ndice

I. INFORMACIN GENERAL DE LA ASIGNATURA .............................................. 6
a. Ficha de identificacin ............................................................................................................. 6
b. Descripcin ............................................................................................................................... 6
c. Fundamentacin terica de la asignatura ............................................................................ 7
d. Propsito ................................................................................................................................... 8
e. Competencia(s) a desarrollar ................................................................................................. 9
f. Temario ....................................................................................................................................... 9
g. Metodologa de trabajo ......................................................................................................... 11
h. Evaluacin ............................................................................................................................... 11
i. Fuentes de consulta ................................................................................................................ 12
UNIDAD 1. INTRODUCCIN AL ANLISIS ORIENTADO A OBJETOS .............. 13
Presentacin de la unidad ......................................................................................................... 13
Propsito ...................................................................................................................................... 13
Competencia especfica ............................................................................................................ 13
Actividad 1. Presentacin .......................................................................................................... 13
1.1. Generalidades ..................................................................................................................... 14
1.1.1. Definicin .......................................................................................................................... 15
1.1.2. Caractersticas ................................................................................................................. 17
1.1.3. Ventajas ............................................................................................................................ 19
Actividad 2. Caractersticas y ventajas de la programacin OO ......................................... 20
1.2. Identificacin y conceptos bsicos de modelos orientados a objetos ........................ 20
1.2.1. Abstraccin ....................................................................................................................... 22
1.2.2. Encapsulamiento ............................................................................................................. 22
1.2.3. Modularidad ...................................................................................................................... 23
1.2.4. Herencia ............................................................................................................................ 23
1.2.5. Polimorfismo ..................................................................................................................... 24
Actividad 3. Ejemplos de sistemas .......................................................................................... 25
1.3. Ciclo de vida del software y tipos de ciclos .................................................................... 25

1.3.1. Definicin .......................................................................................................................... 25
1.3.2. Espiral ............................................................................................................................... 26
1.3.3. Cascada ............................................................................................................................ 27
1.3.4. Incremental ....................................................................................................................... 28
Actividad 4. Conceptos bsicos de los modelos Orientados a objetos ............................. 29
Autoevaluacin ........................................................................................................................... 29
Evidencia de aprendizaje. Mapa mental de los modelos orientados a objetos ................ 29
Cierre de la unidad ..................................................................................................................... 30
Para saber ms ........................................................................................................................... 30
Fuentes de consulta ................................................................................................................... 31
UNIDAD 2. REQUERIMIENTOS PARA EL ANLISIS DEL DISEO ORIENTADO
A OBJETOS .......................................................................................................... 32
Propsito ...................................................................................................................................... 32
2.1. Levantamiento de requerimientos .................................................................................... 34
Actividad 1. Anlisis y diseo en un programa orientado a objetos ................................... 36
2.2. Documentacin para levantamientos y especificaciones ............................................. 36
2.2.1. Documentacin ................................................................................................................ 37
2.2.2. Especificaciones .............................................................................................................. 38
2.3. Estndares de Especificacin ........................................................................................... 38
2.3.1. Fases de la estandarizacin .......................................................................................... 39
2.3.2. Anlisis de restricciones ................................................................................................. 40
Actividad 2. Requerimientos, fases y restricciones para disear un programa ................ 41
2.4. Modelos del desarrollo del software ................................................................................ 41
2.4.1. giles ................................................................................................................................. 43
2.4.2. Predictivos ........................................................................................................................ 43
Actividad 3. Cuadro Comparativo de modelos giles y predictivos .................................... 45
Autoevaluacin ........................................................................................................................... 46
Evidencia de aprendizaje. Requerimientos para disear un programa Orientado a
Objetos ......................................................................................................................................... 46

UNIDAD 3. METODOLOGAS DE DISEO PARA LA GENERACIN DE
SISTEMAS ORIENTADOS A OBJETOS .............................................................. 48
Propsito ...................................................................................................................................... 50
3.1. Booch .................................................................................................................................... 51
3.1.1. Introduccin ...................................................................................................................... 51
3.1.2. Modelos ............................................................................................................................. 52
3.2. OOSE ................................................................................................................................... 57
3.2.1. Introduccin ...................................................................................................................... 58
3.2.2. Modelos ............................................................................................................................. 60
3.3. OMT ...................................................................................................................................... 63
3.3.1. Introduccin ...................................................................................................................... 64
3.3.2. Modelos ............................................................................................................................. 65
Actividad 1. Metodologa para la generacin de sistemas OO ........................................... 67
3.4. UML....................................................................................................................................... 67
3.4.1. Introduccin ...................................................................................................................... 68
3.4.2. OCL (Lenguaje de Especificaciones de Objetos)....................................................... 70
Actividad 2. Cuadro comparativo de las diferentes metodologas ...................................... 71
Autoevaluacin ........................................................................................................................... 72
Evidencia de aprendizaje. Cuadro comparativo de los mtodos de modelado ................ 72
Para saber ms ........................................................................................................................... 73
UNIDAD 4. DISEO ORIENTADO A OBJETOS CON UML (LENGUAJE
UNIFICADO DE MODELADO) .............................................................................. 75
Propsito ...................................................................................................................................... 75

4.1. Representacin de objetos y clases con UML ............................................................... 76
4.1.1. Representacin de clases con UML ............................................................................. 76
4.1.2. Representacin de objetos con UML ........................................................................... 77
Actividad 1. Representacin de clases y objetos con UML ................................................. 78
4.2. Diagramas y documentacin para el diseo del software con UML ........................... 79
4.2.1. Casos de uso ................................................................................................................... 80
4.2.2. Escenarios del caso de uso ........................................................................................... 85
4.2.3. Diagramas de actividades .............................................................................................. 86
4.2.4. Diagrama secuencial ...................................................................................................... 88
4.2.5. Diagrama de clase .......................................................................................................... 89
Actividad 2. Aplicacin de diagramas ...................................................................................... 91
4.2.6. Diagrama de grfico de estado ..................................................................................... 92
Actividad 3. Diseo de diagramas en UML ............................................................................ 93
Autoevaluacin ........................................................................................................................... 94
Evidencia de aprendizaje. Diagramas UML ........................................................................... 94
Para saber ms ........................................................................................................................... 95



I. Informacin general de la asignatura

a. Ficha de identificacin

Nombre de la Ingeniera: Desarrollo de software
Nombre del curso o asignatura: Anlisis y diseo orientado a objetos
Clave de asignatura: 160920413 / 150920413
Seriacin: No aplica
Cuatrimestre: Cuarto
Horas contempladas: 72 horas

b. Descripcin

El hecho de pensar cmo o por dnde empezar a analizar los datos para disear un
programa de computadora es una labor complicada, ms aun si el programa que se
quiere realizar est pensado en la metodologa con orientacin a objetos, la cual data de
los aos cincuenta y no se usaba hasta hace poco porque la tecnologa no estaba acorde
con su implementacin. Hoy en da, la tecnologa orientada a objetos se aplica desde que
se hace el anlisis de un problema y sobre todo en el diseo de un programa que luego
ser pasado a cdigo en un lenguaje especfico para dar solucin a la necesidad de
automatizar la informacin de la empresa.

Los conceptos de anlisis y diseo orientado a objetos surgen a partir de los lenguajes
modernos de programacin. Aprovechando los beneficios de trabajar bajo este enfoque,
si se hace un buen anlisis y diseo previo, el proceso de programacin se vuelve fcil de
desarrollar y se obtienen mejores resultados.

En el anlisis orientado a objetos se desarrollan una serie de modelos que nos orientan
sobre el software o lenguaje de programacin a trabajar y as satisfacer un conjunto de
requisitos definidos por el cliente. El modelo del anlisis orientado a objetos ilustra la
informacin, el funcionamiento y el comportamiento que llevar el flujo de la informacin
desde que se introduce, hasta lo que la computadora va a arrojar como resultado,
transformando el anlisis de los datos en un modelo de diseo que sirve como
anteproyecto para la construccin de software, convirtindolo as incluso en un software
de fcil mantenimiento.


c. Fundamentacin terica de la asignatura

La asignatura de Anlisis y diseo orientado a objetos tiene como funcin principal que se
aprenda a responder a las necesidades de flexibilidad en los sistemas de informacin,
mediante el manejo de los conceptos bsicos de los modelos orientados a objetos tales
como herencia, polimorfismo, abstraccin, etc. Dichos modelos han sido desarrollados
para que los sistemas sean ms flexibles y el mantenimiento se vuelva sencillo. Mientras
que el desarrollo orientado a objeto involucra una fase de anlisis y diseo ms amplia,
esta inversin se traduce en menores costos de mantenimiento.

Existen varias metodologas orientadas a objetos; a pesar de que tienen variantes entre
ellas, todas trabajan con el mismo paradigma, por tanto se basan en los mismos
fundamentos. Las tcnicas para el anlisis y diseo Orientadas a Objetos todava estn
en desarrollo, esto debido a que la programacin misma an se encuentra en esta etapa.

Han surgido tantas metodologas que tratan este modelo de programacin, siendo una de
las ms usadas UML (Lenguaje Unificado de Modelado) por ser ms eficiente en este
enfoque. Por lo anterior, en esta asignatura es necesario abordar una parte introductoria
sobre esta metodologa (unidad 1), donde se abarcan conceptos generales del anlisis,
los modelos orientados a objetos y el ciclo de vida del software. Estos conceptos se
utilizarn para poder llegar a la unidad 2, en la que se elaboran los papeles de trabajo
para este tipo de anlisis con orientacin a objetos. As pues las unidades 1 y 2 estn
enfocadas al anlisis, mientras que en las unidades 3 y 4 se abarca lo concerniente al
diseo orientado a objetos.

Desde el inicio de la primera unidad, el estudiante interacta con las herramientas del aula
virtual, como foros y bases de datos. Posteriormente, se llevan a cabo trabajos, as como
tambin se presentan actividades de investigacin que complementan los contenidos, lo
que permite ejercitar y presentar sus evidencias de aprendizaje de los temas vistos en
cada unidad.

El enfoque terico metodolgico en el cual se sustenta la asignatura es un enfoque mixto,
donde se considerarn los siguientes aspectos:
Criterio cuantitativo: nmero de aportaciones: mnimo 2/tema a discutir.
Criterio cualitativo a travs de escalas:
o Excelente: 100
o Bien: 80
o Regular: 60
o Insuficiente: 50


d. Propsito

El propsito general de la asignatura es realizar los diagramas que se requieren usando
como base el anlisis de un sistema con orientacin a objetos mediante las herramientas
de un lenguaje grfico -como UML (Lenguaje Unificado de Modelado)- para visualizar,
especificar, construir y documentar un sistema.

La asignatura de Anlisis y diseo orientado a objetos forma parte del cuarto cuatrimestre
de la Ingeniera en Desarrollo de software. La materia sirve de apoyo para la asignatura
de Programacin orientada a objetos, adems servir como base para las asignaturas de
Programacin orientada a objetos II y III de posteriores cuatrimestres y tiene como
asignatura precedente a Fundamentos de programacin.

El curso se encuentra conformado por cuatro unidades:

1. Introduccin al anlisis orientado a objetos
2. Requerimientos para el anlisis del diseo orientado a objetos
3. Metodologas de diseo para la generacin de sistemas orientados a objetos
4. Diseo orientado a objetos con UML (Lenguaje Unificado de Modelado)

En la unidad 1 se presenta una introduccin al anlisis orientado a objetos, desde su
definicin y caractersticas, hasta las ventajas de hacer un buen anlisis para lograr un
diseo orientado a objetos, as como los conceptos bsicos de modelos orientados a
objetos y lo referente al ciclo de vida del software. La unidad 2 trata sobre los papeles de
trabajo para el anlisis del diseo orientado a objetos, donde se revisa el levantamiento
de requerimientos, los estndares de especificacin y los modelos del desarrollo de
software. En la unidad 3 se exponen las diferentes metodologas para el diseo de
sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /
Ingeniera de Software Orientado a Objetos), OMT (Object Modeling Technique / Tcnica
de Modelado de Objetos) y UML (Unified Modeling Language / Lenguaje Unificado de
Modelado). Finalmente, en la unidad 4, se trabaja el diseo orientado a objetos con
diagramas UML, con el fin de tener un diagrama de fcil entendimiento que podr ser
convertido en un diseo con orientacin a objetos, logrando que sea fcil de codificar en
cualquier lenguaje con programacin orientada a objetos.


e. Competencia(s) a desarrollar

Competencia general:

Diagramar la estructura de un sistema orientado a objetos para su diseo con base en el
anlisis del sistema mediante el uso de UML (Lenguaje Unificado de Modelado).

Competencias especficas:
Identificar las etapas de un sistema orientado a objetos para decidir su ciclo de
vida, utilizando los conceptos de orientacin a objetos.
Distinguir los requerimientos del sistema orientado a objetos en su etapa de
anlisis para definir su diseo mediante tcnicas y estndares de especificacin.
Comparar las metodologas de diseo para la generacin de sistemas orientados a
objetos mediante los diagramas con los mtodos de modelado Booch, OOSE,
OMTy UML.
Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos
mediante el mtodo de modelado UML.

f. Temario

Unidad 1. Introduccin al anlisis orientado a objetos
1.1. Generalidades
1.1.1. Definicin
1.1.2. Caractersticas
1.1.3. Ventajas
1.2. Identificacin y conceptos bsicos de modelos orientados a objetos
1.2.1. Abstraccin
1.2.2. Encapsulamiento
1.2.3. Modularidad
1.2.4. Herencia
1.2.5. Polimorfismo
1.3. Ciclo de vida del software y tipos de ciclos
1.3.1. Definicin
1.3.2. Espiral
1.3.3. Cascada
1.3.4. Incremental
Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos
2.1 . Levantamiento de requerimientos

2.1.1. Introduccin a los requerimientos
2.1.2. Actividades para el levantamiento de requerimientos
2.2 . Documentacin para levantamientos y especificaciones
2.2.1 Documentacin
2.2.2 Especificaciones
2.3 . Estndares de especificacin
2.3.1 Fases de la estandarizacin
2.3.2 Anlisis de restricciones
2.4 . Modelos del desarrollo de software
2.4.1. giles
2.4.2. Predictivos
Unidad 3. Metodologas de diseo para la generacin de sistemas orientados a objetos
3.1. Booch
3.1.1. Introduccin
3.1.2. Modelos
3.2. OOSE
3.2.1. Introduccin
3.2.2. Modelos
3.3. OMT
3.3.1. Introduccin
3.3.2. Modelos
3.4. UML
3.4.1. Introduccin
3.4.2. OCL (Lenguaje de Especificacin de Objetos)
Unidad 4. Diseo orientado a objetos con UML (Lenguaje Unificado de Modelado)
4.1. Representacin de objetos y clases con UML
4.1.1. Representacin de clases con UML
4.1.2. Representacin de objetos con UML
4.2. Diagramas y documentacin para el diseo del software con UML
4.2.1. Casos de uso
4.2.2. Escenarios del caso de uso
4.2.3. Diagramas de actividades
4.2.4. Diagrama secuencial
4.2.5. Diagrama de clase
4.2.6. Diagrama de grfico de estado



g. Metodologa de trabajo

El aprendizaje basado en la resolucin de problemas es una metodologa en la que se
presentan situaciones diversas para que se lleve a cabo la aplicacin de frmulas,
algoritmos y procedimientos, as mismo rutinas que permitan ejercitar y poner en prctica
los conocimientos y procedimientos para promover el reforzamiento de lo aprendido o la
resolucin de dudas, as como el aprendizaje significativo, al comprobar los elementos
tericos.

Al aplicar este tipo de metodologa en la asignatura, tambin se toman en cuenta:
El uso de las siguientes herramientas tecnolgicas: a) un foro general al inicio de la
asignatura cuyo propsito es favorecer la comunicacin y el conocimiento entre los
estudiantes, b) foros que sirven como base para participar en temas propuestos y
obtener un mayor conocimiento acerca de los temas de cada unidad.
La realizacin de actividades formativas, entre las que destacan: tareas en las que
se analiza el tema y se selecciona un ejemplo u otras en las que dado un ejemplo
especifico se pide entregar documentacin a requerimientos, tambin elaborar
secuencias de tiempo investigaciones y disear diagramas como parte final para la
aplicacin del conocimiento adquirido.
La construccin del portafolio de evidencias (e-portafolio), el cual consta de la
elaboracin de mapas mentales para evidenciar el conocimiento adquirido,
levantamientos de requerimientos, cuadros sinpticos y diseo de diagramas con
problemas relativos a los temas abordados en cada una de las unidades que
integran la asignatura, que reflejen la utilizacin de los conocimientos adquiridos a lo
largo de sta.
La realizacin de actividades de autoevaluacin que den cuenta del grado de
aprendizaje adquirido y refuercen los conocimientos.

h. Evaluacin

En el marco del Programa ESAD, la evaluacin se conceptualiza como un proceso
participativo, sistemtico y ordenado que inicia desde el momento en que el estudiante
ingresa al aula virtual, por lo que se le considera desde un enfoque integral y continuo.

Por lo anterior, para aprobar la asignatura, se espera la participacin responsable y activa
del estudiante, as como una comunicacin estrecha con su Facilitador(a) para que pueda
evaluar objetivamente su desempeo, para lo cual es necesaria la recoleccin de

evidencias que permitan apreciar el proceso de aprendizaje de contenidos: declarativos,
procedimentales y actitudinales.

En este contexto la evaluacin es parte del proceso de aprendizaje, en el que la
retroalimentacin permanente es fundamental para promover el aprendizaje significativo y
reconocer el esfuerzo. Es requisito indispensable la entrega oportuna de cada una de las
tareas, actividades y evidencias, as como la participacin en foros y dems actividades
programadas en cada una de las unidades, y conforme a las indicaciones dadas. La
calificacin se asignar de acuerdo con la rbrica establecida para cada actividad, por lo
que es importante que el estudiante la revise antes de realizar las actividades.

A continuacin presentamos el esquema general de evaluacin.

ESQUEMA DE EVALUACIN
Evaluacin
continua
Interacciones individuales y
colaborativas
10%
Tareas 30%
E-portafolio.
50%
Evidencias 40%
Autorreflexiones 10%
Examen 10%
CALIFICACIN
FINAL
100%

Cabe sealar que para aprobar la asignatura, se debe de obtener la calificacin mnima
indicada por ESAD.

i. Fuentes de consulta

Bibliografa bsica

Booch-Grady (1996). Anlisis y Diseo Orientado a objetos con aplicaciones.
Mxico: Pearson Educacin.
Kendall, E. (2005). Anlisis y Diseo de sistemas. Mxico: Pearson Educacin.
Seen, J. (1990). Anlisis y Diseo de sistemas de Informacin. Mxico: Mc Graw
Hill.

Bibliografa complementaria

Sommerville, I. (2005). Ingeniera del Software. Mxico: Pearson Educacin.


Unidad 1. Introduccin al anlisis orientado a objetos

Presentacin de la unidad

Bienvenido(a) a la asignatura Anlisis y diseo orientado a objetos. En esta primera
unidad se expondrn los principios fundamentales de un buen anlisis para hacer un
correcto diseo y as poder programar con orientacin a objetos, lo que permitir dar
cumplimiento al propsito de la unidad.

En la primera parte de esta unidad te enfrentars en la seccin de anlisis y diseo, con
algunos conceptos bsicos como la definicin, las caractersticas y las ventajas de hacer
un anlisis previo de la informacin y debers conocer, en la segunda parte de esta
unidad, los conceptos de orientacin a objetos para que cuando hagas tu diseo sepas
darle ese enfoque, tambin distinguirs las caractersticas de este tipo de programacin.
Finalmente, conocers el ciclo de vida del software y algunos tipos de ciclos. Toda esta
informacin es el principio bsico de un buen anlisis de diseo orientado a objetos.

Propsito

Conocer los atributos de los modelos orientados a objetos para poder establecer las
necesidades del diseo de un sistema con estas caractersticas, as como ubicar las
etapas de vida del software.

Competencia especfica

Identificar las etapas de un sistema orientado a objetos para decidir su ciclo de vida,
utilizando los conceptos de orientacin a objetos.

Actividad 1. Presentacin

Antes de entrar de lleno en el estudio de la asignatura, te presentamos un foro de
discusin general, el cual fue creado con la finalidad de que te presentes con tus
compaeros y comentes cualquier asunto relacionado con la asignatura; en l, conocers
a tus compaeros de grupo y entre todos podrn apoyarse para resolver dudas,
inquietudes, externar comentarios, etctera.


Para comenzar tu participacin, ingresa al foro Presentacin.

1.1. Generalidades

El objetivo principal del anlisis orientado a objetos (AOO), es desarrollar un software
capaz de cubrir con las necesidades esenciales del usuario final, y su diseo se enfoca
en los objetos.

El anlisis orientado a objetos y su diseo se basa en definir una serie de actividades
relevantes al problema que se va a resolver, en donde son comnmente utilizadas las
operaciones y atributos asociados. Para cumplir con esto se deben tener en cuenta las
siguientes tareas:

1.- Debe de existir una comunicacin sobre los requisitos bsicos del usuario ya que
ser el usuario final del software.
2.- Se deben definir los mtodos a utilizar para el anlisis.
3.- Se debe definir la jerarqua de los mtodos utilizados para el anlisis.
4.- Deben existir relaciones de objeto a objeto, as como todas sus conexiones.
5.- Debe modelarse el comportamiento del objeto.

Las actividades anteriores se aplican de forma iterativa hasta que el modelo est
completo.

El software orientado a objetos es ms fcil de mantener debido a que su estructura es
inherentemente poco acoplada. Adems los sistemas orientados a objetos son ms
fciles de adaptar y escalables.

El enfoque realizado sobre el desarrollo orientado a objetos no debe implicar hacer las
tareas diferentes del enfoque clsico de desarrollo de software puesto que se
desarrollan actividades similares en un proceso evolutivo.

El modelo orientado a objetos tiene como caracterstica el hecho de que un elemento
del mundo real se puede representar a travs de sus caractersticas y de sus
comportamientos.

Los conceptos como clase, objeto, instancia, atributos y mtodos, se hacen cotidianos
en el AOO, ya que son parte de su vocabulario.

Los conceptos fundamentales que llevan a un diseo de alta calidad son igualmente
aplicables a sistemas desarrollados usando mtodos orientados a objetos. Por esa

razn, un AOO debe exhibir abstracciones de datos y procedimientos que conducen a
una modularidad eficaz.

La gestin de un proyecto de software orientado a objetos por lo general tiene
actividades como:
1.- Establecer un proceso comn para el proyecto.
2.- Usar mtricas para desarrollar estimaciones de tiempo y esfuerzo.
3.- Especificar productos de trabajo e hitos que permitirn medir el progreso.
4.- Tener puntos de comprobacin para la gestin de la calidad y control.
5.- Controlar cambios que se generan durante el progreso del proyecto.
6.- Realizar el seguimiento y control del progreso.

El AOO se basa en un conjunto de principios bsicos comnmente usados:
1.- Modelado de la informacin.
2.- Descripcin de funciones.
3.- Representacin del comportamiento del modelo.
4.- Desarrollo de modelos de datos, funcional y de comportamiento.

El anlisis y desarrollo orientado a objetos puede ser interpretado como el conjunto de
disciplinas que desarrollan y modelan un software que facilita la construccin de
sistemas de informacin complejos a partir de la formacin de sus componentes.

Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para construir
sistemas de software complejos a partir de unidades de software, el enfoque del AOO
debe ser capaz de manipular sistemas grandes y pequeos que sean flexibles con
facilidad de mantenimiento y capaces de evolucionar con respecto a las necesidades y
requerimientos del usuario final.

1.1.1. Definicin

Para comenzar a entender en qu consiste el anlisis y diseo de software orientado a
objetos, empezaremos por definir el trmino orientado a objetos, pero vayamos por
partes, como se muestra a continuacin:

Objeto: Instancia de una clase especfica. Los objetos heredan los atributos y
operaciones de una clase.

Clase: Representa a una entidad que tiene un estado interno y un comportamiento
caracterstico.

Atributos: Son los datos a los que se refiere el estado del objeto (Booch-Grady, 1996).


Los objetos tienen un estado interno y un comportamiento, el estado de un
determinado objeto es un conjunto de parmetros con valores que lo caracterizan.
Estos parmetros son atributos y representan lo mismo que los campos de una tabla
de una base de datos o las variables de un programa estructurado, por ejemplo:
La edad de una persona
El nombre de un animal
La altura de un edificio
La jornada de un trabajo

El comportamiento de un objeto se forma por el conjunto de operaciones que se
pueden realizar. Cada una de esas operaciones recibe el nombre de mtodo. Los
mtodos podran ser:
Dibujar un tringulo
Asignar laboratorio de trabajo a un grupo
Prestar un libro de la biblioteca

Cada objeto de una clase tiene sus propios atributos, que describen y caracterizan el
estado en cada momento, y un conjunto de mtodos, sobre los cuales ejecuta las
operaciones que manifiesta su comportamiento.

El anlisis orientado a objetos (AOO) construye un modelo orientado a objetos y a las
clases que se basan en la comprensin de los conceptos orientado a objetos (OO).

El enfoque orientado a objetos permite que los objetos estn auto-contenidos. Los
objetos existen por s mismos, con una funcionalidad para invocar comportamientos de
otros objetos. Por definicin son modulares, es decir, pequeas unidades lgicas de
cdigos independientes entre s que se comunican entre ellas mediante mensajes en su
construccin. Esto quiere decir que son entidades completas y, por lo tanto, tienden a
ser altamente reutilizables.

Las aplicaciones orientadas a objetos se constituyen sobre el paradigma de los
mensajes a otros objetos.

Por lo general la mayora de los programadores desarrolla sobre un lenguaje y solo
utiliza su propio estilo de programacin. Desarrollan sobre un paradigma forzado por el
lenguaje que utilizan, tienden a no enfrentarse a mtodos alternativos de resolucin de
un problema y como resultado se presentan con la dificultad de ver las ventajas de elegir
un estilo ms apropiado al problema a manejar. Autores como Bobrow y Stefik (1986,
citados en Booch-Grady, 1996) sugieren que existen cuatro clases de estilo de
programacin:
Orientada a procedimientos (Algoritmos).

Orientada a objetos (Clases y objetos).
Orientada a la lgica (Expresado en clculo de predicados).
Orientada a reglas (Reglas if-Then).

Anlisis y diseo orientado a objetos (ADOO) es un enfoque de la ingeniera de software
que modela un sistema como un grupo de objetos que interactan entre s. Este enfoque
representa un dominio en trminos de conceptos compuestos por verbos y sustantivos,
clasificados de acuerdo a su dependencia funcional.

En este mtodo de anlisis y diseo se crea un conjunto de modelos utilizando una
notacin acordada, como por ejemplo, el lenguaje unificado de modelado (UML). ADOO
aplica tcnicas de modelado de objetos para analizar los requerimientos en un contexto
(un sistema de negocio, un conjunto de mdulos de software) y para disear una solucin
para mejorar los procesos involucrados. Este mtodo no est restringido al diseo de
programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las
metodologas de anlisis y diseo ms modernas son casos de uso guiados a travs de
requerimientos, diseo, implementacin, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estndar usado
en anlisis y diseo orientado a objetos.

Las estrategias que se utilizan para hacer un correcto desarrollo orientado a objetos son:
anlisis, diseo y programacin. En el anlisis se consideran las actividades que hay que
hacer para desarrollar un programa OO y se identifican los objetos, transformndolos en
entidades y operaciones para asociarlos con el problema a resolver. En el diseo, los
objetos se relacionan con la solucin del problema. Finalmente, en la programacin se
hace la codificacin del problema en algn lenguaje con orientacin a objetos.

1.1.2. Caractersticas

El modelo AOO se basa en el concepto de objeto. Un objeto que tiene estado,
comportamiento e identidad. La estructura y el comportamiento de los objetos son
similares y estn definidos en su clase comn.

De tal modo, los sistemas deben estar funcionando siempre de manera correcta, su
complejidad a veces es tan grande que el mismo ser humano o su capacidad intelectual
se ve excedida, por lo que resulta imposible comprenderlo en su totalidad por una sola
persona.

As, el software es complejo de forma innata, es una caracterstica esencial de l. Es
complejo porque hereda la complejidad del problema, la dificultad de gestionar el proceso

de desarrollo, la flexibilidad que se puede alcanzar a travs del software y los problemas
que plantea:

1. El problema presenta tantos requisitos que compiten entre s o se contradicen, y
esas contradicciones existen porque los usuarios no saben expresar sus necesidades
de forma clara para que las otras personas que participan en el proyecto lo puedan
entender.
2. Los requisitos, adems, son cambiados con frecuencia durante el desarrollo,
incluso porque la mera existencia de un proyecto de solucin altera al sistema real.
3. Un sistema grande, debido a la inversin financiera que implica, no puede
desecharse y reemplazarse por uno nuevo cada vez que los requisitos cambian, debe
evolucionar, considerando:
Evolucin del software: responder al cambio de requerimientos.
Mantenimiento del software: corregir errores.
Conservacin del software: emplear recursos para mantener en operacin un elemento
de software anticuado y decadente.
4. La principal tarea del grupo de desarrollo es dar una ilusin de simplicidad para los
usuarios de esta complejidad arbitraria del problema, se hace lo posible por escribir
menos cdigo pero a veces es imposible y ms en un sistema tan grande, por lo que
se debe recurrir a la aplicacin de varias tcnicas de re-utilizacin de cdigo
existente.
5. Debe tambin enfrentarse la existencia de miles de mdulos separados y esto
implica un grupo de desarrolladores, nunca una nica persona.
6. Un proyecto de software es muy frecuentemente apoyado en pilares construidos
por los mismos desarrolladores, por lo que el desarrollo del proyecto de software
sigue siendo una tarea muy laboriosa.
7. En algunos sistemas, una pequea modificacin en la entrada provoca una
pequea modificacin en la salida. Mientras que en otros, y sobre todo de gran
tamao, se percibe una explosin combinatoria que hace que la salida se modifique
enormemente.
8. Se intenta disear los sistemas con una separacin de intereses, de forma que el
comportamiento de una parte del sistema tenga el mnimo impacto en el
comportamiento de otra parte del sistema.
9. En un sistema de gran volumen, uno debe contentarse con un grado de confianza
determinado a lo que refiere su correccin, ya que no puede llevarse a cabo una
prueba a fondo exhaustiva por no tener las herramientas matemticas ni intelectuales
para un sistema no continuo.
10. Las consecuencias de la complejidad ilimitada. Mientras ms complejo es el
sistema, ms abierto est al derrumbamiento total.
11. Crisis del software: ha existido tanto tiempo que debe considerarse normal. Es
cuando se pretende dominar la complejidad del sistema a un extremo que lleva al

presupuesto a niveles excedentes y que transforman en deficiente al sistema
respecto a los requerimientos fijados.

1.1.3. Ventajas

Los beneficios del enfoque OO, de acuerdo con Booch-Grady (1996), son:
Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos
los lenguajes de programacin basados en objetos y los orientados a objetos,
como Smalltalk, Object Pascal, C++, CLOS, Ada y recientemente Java.
Segundo, el uso del modelo OO alienta el re-uso no solo del software, sino de
diseos completos.
Tercero, produce sistemas que estn construidos en formas intermedias estables
y por ello son ms resistentes al cambio en especificaciones y tecnologa.

Se considera que el principal beneficio del AOO, es que da un esquema para formalizar
el modelo real.

El anlisis orientado a objetos (AOO) es un mtodo de anlisis que examina los
requerimientos desde la perspectiva de las clases y objetos encontrados en el
vocabulario del dominio del problema. El diseo orientado a objetos es un mtodo de
diseo que abarca el proceso de descomposicin orientado a objetos y una notacin
para representar ambos modelos (lgico y fsico), como los modelos estticos y
dinmicos del sistema bajo diseo.

Dentro de las metodologas del anlisis y diseo orientado a objetos, hay una variedad
de mtodos en la actualidad. Muchos de los mtodos pueden ser clasificados como
orientados a objetos porque soportan de manera central los conceptos de la orientacin
a objetos. Algunas de las metodologas ms conocidas y estudiadas hasta antes de UML
(Jacobson 1996, citado en Booch-Grady, 1996) son:

METODOLOGA AUTOR
Diseo orientado a
objetos (DOO)
Grady Booch
Tcnica de modelado de
objetos (TMO)
Rumbaugh
Anlisis orientado a
objetos (AOO)
Coad/Yourdon
Jerarqua de diseo
orientada a objetos
(JDOO)
ESA
Diseo estructurado Wasserman

orientado a objetos
(DEOO)
Anlisis de sistemas
orientado a objetos
(ASOO)
Shaler y Mellor, entre
otros

Actualmente las metodologas ms importantes de anlisis y diseo de sistemas
orientados a objetos se han basado en lo que es el UML, bajo el respaldo del Grupo
Administrador de objetos.

El modelo de objetos ha demostrado ser aplicable a una amplia variedad de dominios de
problema. Hoy en da, el ADOO puede que sea el nico mtodo que logre emplearse para
atacar la complejidad innata de muchos sistemas grandes. Sin embargo, puede no ser
aconsejable en dominios, no por razones tcnicas sino por cuestiones como falta de
personal con entrenamiento adecuado o buenos entornos de desarrollo.

Lo interesante de la Programacin Orientada a Objetos (POO) es que proporciona
conceptos y herramientas con las cuales se modela y representa el mundo real tan
fielmente como sea posible.

Actividad 2. Caractersticas y ventajas de la programacin OO

Con el fin de reflexionar sobre la importancia de hacer un adecuado anlisis y diseo
previo para realizar un buen programa, tomando en cuenta los temas abordados, realiza
lo que se te pide a continuacin:

1. Retoma los conceptos desarrollados hasta ahora.

2. Identifica las diferencias entre anlisis, diseo y programacin orientada a objetos.

3. Ingresa al foro y realiza lo que en l se te pide.

1.2. Identificacin y conceptos bsicos de modelos orientados a
objetos

El anlisis orientado a objetos es una forma de hacer frente a la comprensin y solucin
de problemas, usando modelos a partir de conceptos. La pieza fundamental es el objeto,
el cual se combina en una sola entidad.


Para dar nfasis sobre los conceptos en el anlisis orientado a objetos, a continuacin se
detallan los ms bsicos o utilizados con mayor frecuencia.

Objeto: Es una entidad bien definida, real o abstracta, que tiene sentido sobre el contexto
de alguna aplicacin y un papel bien definido. A su vez se puede diferenciar en dos tipos:
Concretos: Ejemplo de objetos concreto, una unidad de almacenamiento, un
archivo de computadora, un automvil, un profesor.
Conceptuales: Ejemplo de objetos conceptuales, un programa de computadora,
una variable de programacin, un pensamiento.

Atributo: Es un valor atribuido a un objeto, por ejemplo un alumno es un objeto y sus
atributos podran ser su nmero de control, su nombre y su calificacin. Se entiende que
se pueden llegar a tener ms atributos, pero si el contexto de la aplicacin es solo obtener
un resultado especfico, los atributos sern los nicos que son relevantes para esa
aplicacin.

Comportamiento: Es el conjunto de cada accin o transformacin que el objeto ejecuta,
tambin podra ser llamado operacin y mtodo. Por ejemplo, para el objeto alumno se
requiere de algunas acciones y transformaciones: asignar calificacin, leer nombre y leer
nmero de control; estas acciones representan el comportamiento del objeto alumno. En
el caso de asignar calificacin, leer nombre y leer nmero de control, se refieren a
transformaciones, ya que modificarn el valor de la calificacin final.

Identificacin: Cada objeto posee una identificacin mediante la cual se puede hacer
alusin a l de modo exclusivo.

Clase: describe propiedades importantes para una aplicacin y que ignora el resto. La
seleccin de clases es arbitraria y depende de la aplicacin.

Instancia: Se considera que cada objeto es una instancia de su clase. Toda clase
describe un conjunto posiblemente finito de objetos individuales.

Identidad. Se refiere a que cada objeto conserva de manera inherente su propia
identidad. O sea, 2 objetos son distintos an si el valor de todos sus atributos es idntico.
Por ejemplo, los 8 peones negros de un juego de ajedrez, son todos negros, tienen las
mismas dimensiones, textura, pero todos son diferentes, existen y tienen su propia
identidad. Dos gotas de agua es otro ejemplo de la caracterstica de identidad de los
objetos.

Clasificacin. Se refiere a que los objetos con los mismos atributos y comportamiento
mtodos-, son agrupados en clases. Cada objeto perteneciente a una clase, se dice que
es una instancia de la clase. As que una clase, representa a un posible conjunto infinito

de objetos individuales. Por ejemplo a todos los alumnos que aparecern en la lista de
calificaciones finales, los clasificamos en la clase Alumno. A todos los amigos que
registramos en nuestra agenda, los podemos clasificar en la clase Persona. (Kendall,
2005 y Booch-Grady, 1996)

1.2.1. Abstraccin

En la abstraccin la mente humana modela la realidad en forma de objetos. Para ello
busca semejanzas entre la realidad y la posible implementacin de objetos del programa
que simulen el funcionamiento de los objetos reales.

Los humanos entendemos la realidad como objetos ya definidos y no como un conjunto
de situaciones menores que se unen para dar forma a algo. No es necesario conocer
detalles del cmo, cundo, donde o por qu las cosas, solamente necesitamos saber que
cuando queremos caminar lo haremos y punto.

Es la caracterizacin de un objeto de acuerdo a las propiedades que nos interesen en un
instante de tiempo. Las caractersticas escogidas son relativas a la perspectiva del
observador.

Figura 1.1. Abstraccin.

1.2.2. Encapsulamiento

Cuando un objeto es encapsulado tenemos la libertad de saber qu informacin se hace
pblica o no, para ello podemos hacer privados e inaccesibles los datos de este objeto a
travs otro previamente publicado.

Con esto logramos que los datos solo sean utilizados por su interfaz dejando de lado
cmo est implementada, haciendo as, ms fcil la utilizacin del mismo.


As pues, la manera de ocultar los detalles de la representacin interna de un objeto es
presentando solo la interface para el usuario.

Figura 1.2. Encapsulamiento.

1.2.3. Modularidad

A travs de la modularidad, se propone al programador dividir su aplicacin en varios
mdulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos
con un sentido propio.

Esta fragmentacin disminuye el grado de dificultad del problema al que da respuesta el
programa, pues se afronta ste como un conjunto de problemas de menor dificultad,
adems de facilitar la comprensin del programa.

1.2.4. Herencia

La herencia se base en la capacidad para reflejar la abstraccin que realiza
automticamente y se refiere a compartir atributos y mtodos entre objetos que se
relacionan de manera jerrquica durante un proceso de anlisis de informacin.

Se percibe en la realidad como un agregado de objetos relacionados. Estas
interrelaciones, pueden verse como un conjunto de generalizaciones que se asimilan con
el tiempo. As pues, la herencia es el mecanismo fundamental de relacin entre clases en
la orientacin a objetos.

Del mismo modo, las distintas clases de un programa se organizan mediante la jerarqua.
La representacin de dicha organizacin da lugar a los denominados rboles de herencia:



Figura 1.3. Ejemplo de rbol de herencia

La capacidad de descomponer un problema o concepto en un conjunto de objetos
relacionados entre s, y cuyo comportamiento es fcilmente identificable, puede ser muy
til para el desarrollo de programas informticos. Del mismo modo,

Relaciona las clases de manera jerrquica; una clase padre o superclase sobre otras
clases hijas o subclases.

1.2.5. Polimorfismo

Mediante el denominado paso de mensajes, un objeto puede solicitar de otro objeto que
realice una accin determinada o que modifique su estado. El paso de mensajes se suele
implementar como llamadas a los mtodos de otros objetos.
Desde el punto de vista de la programacin estructurada, esto correspondera con la
llamada a funciones (Garca, s/f: 1)
Ahora bien, el polimorfismo es una caracterstica de la orientacin a objetos, que significa
que un mismo mtodo puede tener diferente manera de realizarse, en las diferentes
clases que haya bajo estudio. Cada objeto perteneciente a una clase y sabe cmo
ejecutar sus propios mtodos. Cuando se programa orientado a objetos, el lenguaje de
programacin automticamente selecciona el mtodo correcto para efectuar una cierta
accin o transformacin sobre el objeto al que se aplica. Por ejemplo, si tenemos los
objetos bicicleta, carro, barco y les aplicamos la operacin Mover, la accin se ejecuta de
manera diferente para cada objeto. Otro ejemplo tpico es el de los objetos de la clase
Figura, digamos crculo, rectngulo, tringulo, apliqumosles la accin de Dibujar, cada
uno de ellos tendr su propio mtodo Dibujar definido, ya que la accin debe
implementarse de manera diferente para cada objeto.



Actividad 3. Ejemplos de sistemas

Esta actividad tiene como finalidad distinguir, en un primer acercamiento, cada uno de
los modelos del ciclo de vida del software. Realiza lo siguiente:

1. En un archivo de texto, realiza ejemplos de sistemas que un cliente pudiera necesitar
(por ejemplo, un sistema que controle una zapatera) y describe qu hara en cada una
de las etapas en los ciclos cascada y espiral incremental.

Ejemplo:
Modelo de ciclo de
vida de zapatera
Etapa Descripcin
Espiral Planificacin En esta etapa en
la zapatera se va
a

2. Guarda tu actividad con la nomenclatura DOO_U1_A3_XXYZ.

3. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

1.3. Ciclo de vida del software y tipos de ciclos

La metodologa para el desarrollo de software tiene pasos establecidos en la realizacin y
administracin de un proyecto para llevarlo a cabo con xito. Para facilitar esto, se debe
dividir un gran proyecto en mdulos ms pequeos llamados etapas. Las acciones que
corresponden en cada una de ellas ayudan a definir entradas y salidas para cada una de
las etapas y sobre todo, normaliza el modo en que administraremos el proyecto.

1.3.1. Definicin

Llevar a cabo la metodologa para el desarrollo del software requiere seguir puntualmente
una serie de pasos o procesos para analizar, disear y realizar un producto software,
desde que surge la necesidad hasta que cumplimos el objetivo por el cual fue creado.

Desde un punto de vista puede considerarse que el ciclo de vida de un software tiene
capas claramente diferenciadas:


Planificacin: planteamiento detallado que los pasos a seguir durante el
desarrollo del proyecto, considerando aspectos de tiempo y dinero.
Implementacin: decidir las actividades que componen la realizacin del
producto.
Produccin: EL proyecto es presentado al cliente o usuario final, sabiendo que
funciona correctamente y responde a los requerimientos solicitados en su
momento.

Figura 1.4. Ciclo de vida del software.

1.3.2. Espiral

Este ciclo de vida puede considerarse una variacin del modelo prototpico que fue
diseado por Boehm en el ao 1988 (citado en Kendall, E., 2005). El modelo se basa en
una serie de ciclos repetitivos para ir ganando madurez en el producto final. Conforme se
va desarrollando el sistema se hace un primer prototipo se presenta al cliente y sobre este
se hacen adecuaciones y nuevos prototipos as se tiene un avance en espiral hasta llegar
a la perfeccin de todas las funcionalidades o mdulos.

En este modelo hay cuatro actividades principales para las etapas:
Planificacin: Relevamiento de requerimientos iniciales o luego de una iteracin.
Anlisis del riesgo: De acuerdo con el relevamiento de requerimientos decidimos
si continuamos con el desarrollo.
Implementacin: Desarrollamos un prototipo basado en los requerimientos.
Evaluacin: El cliente evala el prototipo, si da su conformidad termina el
proyecto. En caso contrario incluimos los nuevos requerimientos solicitados por el
cliente en la siguiente iteracin.



Figura 1.5. Espiral.

1.3.3. Cascada

El primer modelo de proceso de desarrollo de software que se public, se deriv de
procesos de ingeniera de sistemas ms generales (Royce, 1970, citado en Sommerville,
I. 2005).

A continuacin se ve cmo de un diseo previo se deriva otro, dando as su nombre a
Cascada. Cayendo de una a otra, las etapas de este modelo se transforman en
actividades fundamentales de desarrollo:

1. Anlisis y definicin de requerimientos. Los servicios, restricciones y metas del
sistema se definen a partir de las consultas con los usuarios.
2. Diseo del sistema y del software. El proceso de diseo del sistema divide los
requerimientos en sistemas hardware o software.
3. Implementacin y prueba de unidades. Durante esta etapa, el diseo del software se
lleva a cabo como un conjunto o unidades de programas.
4. Integracin y prueba del sistema. Los programas o las unidades individuales de
programas se integran y prueban como un sistema completo para asegurar que se
cumplan los requerimientos del software.

5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), esta
es la fase ms larga del ciclo de vida. El sistema se instala y se pone en funcionamiento
prctico. El mantenimiento implica corregir errores.

Figura 1. 6. Cascada.

1.3.4. Incremental

Este modelo est basado en varios ciclos Cascada realimentados aplicados
repetidamente, es decir que va incrementando las funcionalidades del programa. Se
realiza construyendo por mdulos que cumplen las diferentes funciones del sistema, lo
que permite ir aumentando gradualmente las capacidades del software. Desarrollar un
mdulo o mdulos por separado resulta excelente modelo cuando es desarrollado por
varios programadores.

Figura 1. 7. Incremental.

El modelo de ciclo de vida incremental nos genera algunos beneficios como:
Construir un sistema pequeo siempre es menos riesgoso que construir un
sistema grande.
Como desarrollamos independientemente las funcionalidades, es ms fcil relevar
los requerimientos del usuario.

Si se detecta un error grave solo se desecha la ltima iteracin.
No es necesario disponer de los requerimientos de todas las funcionalidades en el
comienzo del proyecto y adems facilita la labor del desarrollo con la conocida
filosofa de divide y vencers

Este modelo de ciclo de vida no est pensado para cierto tipo de aplicaciones, sino que
est orientado a cierto tipo de usuario o cliente.

Actividad 4. Conceptos bsicos de los modelos Orientados a objetos

Con el fin de distinguir cada uno de los conceptos bsicos de la programacin orientada a
objetos, en esta actividad debes proponer ejemplos que hagan referencia a cada uno de
ellos: abstraccin, encapsulamiento, polimorfismo, modularidad, herencia, jerarqua y
paso de mensajes. Con base en lo anterior, realiza lo que a continuacin se te pide:

1. En un archivo de texto, anota el nombre de cada concepto bsico de los sistemas
orientados a objetos.

2. De acuerdo con la definicin que se revis en los temas anteriores, inventa un ejemplo
de la vida diaria que se apegue a cada uno de ellos.

3. Guarda tu actividad con la nomenclatura DOO_U1_A4_XXYZ.


Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
primera unidad del curso, es necesario que resuelvas la autoevaluacin de la unidad.
Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y
elegir la opcin adecuada para cada uno.

Evidencia de aprendizaje. Mapa mental de los modelos orientados a
objetos

Como parte de la evaluacin de esta unidad, llevars a cabo esta actividad cuyo propsito
es organizar los conceptos abordados a lo largo de la unidad con la finalidad de tener
presente las definiciones revisadas. Realiza lo siguiente:


1. En un archivo de texto o Microsoft Visio, crea un mapa mental con las definiciones de
los temas tratados durante la presente unidad. Recuerda que un mapa mental contiene
cuadros de texto, lneas que representan uniones entre ellos e imgenes que pueden
substituir textos.

2. Consulta la Escala de evaluacin.

3. Guarda tu evidencia con la nomenclatura DOO_U1_EA_XXYY.

4. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin. Recuerda que
puedes volver a enviar tu archivo tomando en cuenta las observaciones de tu
Facilitador(a).

Adems de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a)
presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado
DOO_U1_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta
Autorreflexiones.

Cierre de la unidad

Has concluido la primera unidad del curso. A lo largo de sta se revisaron conceptos
generales sobre el anlisis orientado a objetos, su definicin, caractersticas y ventajas.
Posteriormente identificaste los conceptos bsicos de los modelos orientados a objetos,
tales como abstraccin, encapsulamiento, modularidad, herencia y polimorfismo, cuyo
propsito fue dar un panorama para identificar un modelo orientado a objetos. De la
misma manera, se identificaron los ciclos de vida del software y los tipos de ciclos que
existen al disear un sistema orientado a objetos.

Es aconsejable que revises nuevamente la unidad en caso de que los temas que se
acaban de mencionar no te sean familiares o no los recuerdes, de no ser este tu caso, ya
ests preparado(a) para seguir con la unidad 2, en donde abordars los requerimientos
para el anlisis del diseo orientado a objetos, realizars levantamientos de
requerimientos y la documentacin necesaria, teniendo en cuenta los estndares que
deben cumplir y los tipos de modelos para el desarrollo de software.

Para saber ms

Si deseas saber ms acerca de la programacin orientada a objetos, visita las siguientes
direcciones electrnicas:


I.1. INTRODUCCIN A LA PROGRAMACIN ORIENTADA A OBJETOS:
http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/
Programacin orientada a objetos: http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm

Fuentes de consulta

Bibliografa bsica

Booch-Grady (1996). Anlisis y Diseo Orientado a Objetos con Aplicaciones.
Kendall, E. (2005). Anlisis y Diseo de Sistemas. Mxico: Pearson Educacin.
Seen, J. (1990). Anlisis y Diseo de Sistemas de Informacin. Mxico: Mc Graw
Hill.

Bibliografa complementaria

Ciberaula (2010). Programacin orientada a objetos. Recuperado el 10 de octubre
de 2011 de: http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/
Coad, P. y Yourdon, E. (1990). Object Oriented Programming. USA: Yourdon
Press.
Fowler, M. y Kendall, S. (2000). UML Gota a gota. Mxico: Prentice-Hall.
Fernndez, S. (1995). Fundamentos del diseo y la programacin orientada a
objetos. Mxico: McGraw Hill.
Garca, F. (s/f). I.1. Introduccin a la programacin orientada a objetos.
Recuperado el 10 de octubre de 2011 de:
http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm
Microsoft Autorized Academic (2010). Principles of Components Desing 1518.
USA: Microsoft.
Sommerville, I. (2005). Ingeniera del Software. Mxico: Pearson Educacin.



Unidad 2. Requerimientos para el anlisis del diseo Orientado a
Objetos

Propsito

La especificacin de requisitos es la primera fase de todo ciclo de vida o metodologa de
desarrollo de un proyecto informtico. Dos son sus objetivos principales:

Identificar las necesidades del cliente, es decir, conocer y definir el problema.
Realizar un estudio de viabilidad econmico, tcnico y legal, a partir del cual se
pueda decidir sobre la continuacin del proyecto, teniendo en cuenta las
alternativas de construccin del mismo que se nos planteen.

Estos dos objetivos principales se concretan en una serie de acciones a realizar, unas
tcnicas a aplicar y unos productos a obtener. Resulta obvio (en cualquier contexto, no
solo en el terreno informtico) que un primer paso necesario para solucionar un problema
es tenerlo definido correcta y detalladamente. Esto implica dos cosas:

Es fundamental centrar la necesidad del cliente para poder definir el problema que se va a
resolver, tratando de dejar claro lo que queda dentro y fuera del alcance del mismo. En
este momento se est hablando de la definicin, desde el punto de vista puramente
tcnico, del proyecto. Un aspecto importante a tener en cuenta es la identificacin de los
tipos de usuarios potenciales que tendr el sistema.


Distinguir los requerimientos del sistema orientado a objetos en su etapa de anlisis para
definir su diseo mediante tcnicas y estndares de especificacin.


El trabajo de ir detallando la definicin de un problema en forma de requisitos se realiza
de manera repetitiva, progresiva, incremental. Por un lado, supone la planificacin,

realizacin y evaluacin de las entrevistas con los clientes y usuarios finales del sistema,
que son los portadores de la informacin necesaria para conocer el problema y definir el
proyecto. Por otro lado, supone la identificacin y descomposicin reiterada (hasta el nivel
de detalle que en cada caso sea necesario) de los problemas y necesidades expresados
por el cliente y los usuarios, para as ir redactando un conjunto de requisitos formales.
Principalmente, se utiliza la siguiente tcnica:

Entrevista. Es una conversacin dirigida por objetivos entre un entrevistador, miembro del
equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final.

Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo
siempre a las opiniones del entrevistado. l es nuestra fuente de informacin principal y
de la relacin que establezcamos depende la facilidad o dificultad para conocer sus
necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos;
la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su
futuro trabajo, expertos reticentes a compartir conocimientos.

Durante la realizacin de una entrevista lo habitual es la toma de notas, para redactar ms
tarde el informe de evaluacin de la misma. Para la grabacin en audio o en video es
preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si
esto va a interferir en la entrevista, hacindole sentir incmodo. Pese a su costo, se va
generalizando el uso de videoconferencias para la realizacin de entrevistas remotas, con
la consiguiente comodidad para ambas partes.

Toda entrevista requiere de una preparacin previa: establecer los objetivos, seleccionar
al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir
documentacin, elegir el tipo de preguntas para finalmente utilizar la informacin recabada
para lograr los fines.

Segn el tipo de preguntas, existen diferentes clases de entrevista:

Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la
entrevista, hacia preguntas abiertas.
Deductiva: al principio se hacen preguntas abiertas y se va acotando con
preguntas cada vez ms cerradas.
Mixta: se utilizan ambos tipos de preguntas indistintamente

Algunos ejemplos de Preguntas Abiertas son los siguientes:

Qu le parece nuestra propuesta frente a otras que ha recibido?
Qu servicios le gustara recibir de su sistema?


Para poder formular preguntas cerradas es necesario anticipar las posibles alternativas
de respuesta. Algunos ejemplos de preguntas cerradas:

Firmamos el contrato?
Le gusta nuestro producto?

2.1. Levantamiento de requerimientos

A partir de las entrevistas, reuniones, etc., se ha definido el problema; es decir, se ha
obtenido la Especificacin de Requisitos. En ella se describe lo que el sistema nuevo
debe realizar. Y se ha averiguado, mediante un estudio de viabilidad, si el sistema se
puede desarrollar o no.

Ahora, se va a realizar el siguiente paso del Ciclo de Vida: Anlisis del sistema. Consiste
en analizar los requisitos para centrarse en qu debe hacer el sistema.

Con el Anlisis del sistema se pretende:

Organizar la informacin; es decir, reflejar la informacin del problema en un
formato grfico, ms fcil de manejar. Este formato hace que los requisitos sean
entendibles para el diseador y, a la vez, facilita la comunicacin con el usuario.
Depurar todo aquello que no interesa y concentrarse en lo que debe hacer el
sistema.
Sacar a la superficie y resolver posibles conflictos.
Dividir el problema en sub-problemas ms fciles de resolver.

As pues, toda aplicacin se apoya en tres pilares o consta de tres partes principales:

Procesos. Son la parte funcional de la aplicacin. Reflejan las funciones o tareas
que debe realizar la aplicacin, muestran cmo se transforman los datos.
Datos. Son la parte esttica de la aplicacin. Se refieren a la informacin que se
necesita almacenar.
Eventos. Son la parte dinmica de la aplicacin. Muestran los aspectos del sistema
que cambian con el tiempo. Provocan la ejecucin de la operacin adecuada en
cada momento. Son los que activan la aplicacin (la ponen en marcha) y propagan
esa activacin a lo largo de la aplicacin, desencadenando la ejecucin de otras
operaciones. Los eventos llevan el control de la aplicacin introduciendo el
dinamismo necesario para su ejecucin. Los eventos tienen mucha relacin con la
interfaz de la aplicacin. Porque a travs de la interfaz se introducen los eventos.


Los procesos dicen qu hay que hacer.
Los datos indican con qu hay que hacerlo.
Y los eventos muestran cundo hay que hacerlo.

Los tres pilares son complementarios, no tiene ms importancia uno que otro, se
necesitan los tres. En algunos sistemas predomina ms uno que otro, pero siempre estn
presentes los tres.

Para especificar cada uno de los tres pilares se utilizan Modelos. Un Modelo es una
representacin abstracta de la realidad. Por tanto, como resultado del anlisis se
obtendrn:

Modelo de Procesos, de modelo de Datos y de modelo de Eventos
Modelo de Procesos: recoge qu funciones, actividades, tareas, acciones, debe
realizar la aplicacin y cmo manejar los datos.
Modelo de Datos: describe la informacin que maneja la aplicacin, los datos que
debe almacenar. Y muestra cmo organizarla.
Modelo de Eventos: Indica en qu momento debe ejecutarse cada accin. Para
construir cada modelo hay diferentes tcnicas, algunas son complementarias.

Figura 2.1

En la fase de anlisis se pretende que los modelos (de procesos, de datos y de eventos)
estn lo suficientemente detallados sin llegar a descender al diseo.

El anlisis tiene por objetivo entender el problema: las necesidades del cliente, las
restricciones que se deben cumplir.

El diseo pretende obtener una solucin ptima que cumpla todos los requisitos. Se
orienta hacia la mquina, centrndose en cmo crear un sistema software que rena
todas las necesidades y cumpla todas las restricciones.

El levantamiento de requerimientos incluye tres tipos de actividad:


Sacar requisitos: la tarea de comunicarse con los clientes y los usuarios para
determinarse cules son sus requisitos. Esto a veces tambin se llama acopio de
los requisitos.
Analizar requisitos: determinndose si los requisitos indicados son confusos,
incompletos, ambiguos, o contradictorios, y despus resolviendo estas ediciones.
Requisitos de la grabacin: Los requisitos se pueden documentar en varias
formas, tales como documentos de lenguaje natural, utilice los casos, historias del
usuario, o especificaciones de proceso.

Actividad 1. Anlisis y diseo en un programa orientado a objetos

Con el fin de reflexionar sobre la asignatura, en el foro: Anlisis y diseo en un
programa orientado a objetos construirs un concepto propio, tomando en cuenta los
temas abordados con anterioridad y los comentarios de tus compaeros. Para ello:

1. Retoma las lecturas del tema 2.1.Levantamiento de requerimientos.

2. Identifica todos los requisitos que se deben cumplir antes de un anlisis y diseo
Orientado a objetos.

3. Ingresa al foro, genera una nueva entrada y participa.

2.2. Documentacin para levantamientos y especificaciones

La documentacin rene todas las actividades dedicadas bsicamente a planificar el
proceso de ADOO y mantener los documentos necesarios para los desarrolladores y los
usuarios. El esquema formal que debe tener una especificacin de requisitos es el
siguiente:

1. ndice
2. Descripcin del mbito y alcance del proyecto
3. Lista de usuarios participantes
4. Descripcin del sistema actual
5. Catlogo (priorizado) de requisitos del sistema
a. Funcionales
b. No funcionales
i. Restricciones
ii. De funcionamiento

* Del sistema
* Requisitos software
* Requisitos hardware
iii. Manejo de excepciones
6. Anlisis de alternativas
a. Descripcin de la alternativa 1
b. Descripcin de la alternativa 2
c. Descripcin detallada de la alternativa seleccionada
i. Modelo lgico de procesos
ii. Anlisis costo-beneficio
iii. Diferencias significativas con las dems alternativas
7. Apndices (si es necesario)

2.2.1. Documentacin

La documentacin de los requerimientos, es una de la parte importante durante en el
anlisis. En la prctica es comn describir los requerimientos en un documento, llamado
especificacin de requerimientos del software, su principal objetivo es de comunicar de
forma efectiva los requerimientos, objetivos del dominio.

En primera instancia la documentacin contiene la informacin que aporta el cliente que
encarga la aplicacin, contiene todos los registros de las reuniones de trabajo del grupo
de anlisis.
Documentos bsicos de anlisis orientado a objetos:

Documentos de anlisis
Especificacin de requisitos o requerimientos
Diagramas de casos de uso
Escenarios y sub-escenarios
Prototipos y su evaluacin

Todos los documentos deben estar identificados y codificados.

Identificacin

Es necesario identificar todos los elementos del proceso de desarrollo de software de una
forma nica.

El ttulo debe reflejar de la mejor forma posible sus fines y su funcionalidad.
Descripcin

Autores
Versin. Notacin decimal.
Revisin. Autores
Fecha
Cdigo de cada documento o diagrama

Documentos de anlisis

Contiene la documentacin que aporta el cliente que encarga la aplicacin. Tambin
contiene las actas de las reuniones de trabajo del grupo de anlisis, es necesario un
secretario que tome acta y es necesario aprobar el acta de cada reunin por todos los
miembros.

2.2.2. Especificaciones

Expresa las caractersticas esenciales de un objeto, las cuales distinguen al objeto uno de
otro. A parte de distinguir los objetos tambin provee lmites conceptuales, permitiendo
que se disponga de las caractersticas de un objeto que se necesite.

El objetivo principal de las especificaciones, es en entregar una especificacin de
requisitos que ayuden a determinar de forma completa y correcta el diseo orientado a
objetos.

2.3. Estndares de Especificacin

Las especificaciones del software determina el proceso de comprensin y definicin
sobre los servicios que se requieren del sistema y de identificacin de las restricciones de
funcionamiento y desarrollo del mismo. La ingeniera de requerimientos es un proceso
crtico en el proceso del software, los errores en esta etapa originan problemas
posteriores en el diseo e implementacin del sistema.

En la siguiente figura se muestra el proceso de ingeniera de requerimientos. ste
conduce a la produccin de un documento de requerimientos, que es la especificacin del
sistema. Normalmente en este documento los requerimientos se presentan en dos niveles
de detalle. Los usuarios finales y los clientes necesitan una declaracin de alto nivel de
los requerimientos, mientras que los desarrolladores del sistema necesitan una
especificacin ms detallada de ste.



Figura 2.2

2.3.1. Fases de la estandarizacin

Existen cuatro fases principales en el proceso de estndares de ingeniera de
requerimientos:

1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer
con las tecnologas actuales de software y hardware. El estudio analiza si el sistema
propuesto ser rentable desde un punto de vista de negocios y si se puede desarrollar
dentro de las restricciones de presupuesto existentes. Este estudio debe ser relativamente
econmico de elaborar. EI resultado debe informar si se va a continuar con un anlisis
ms detallado.

2. Obtencin y anlisis de requerimientos. Es el proceso de obtener los requerimientos
del sistema por medio de la observacin de los sistemas existentes, discusiones con los
usuarios potenciales y proveedores, el anlisis de tareas, etctera. Esto puede implicar el
desarrollo de uno o ms modelos y prototipos del sistema que ayudan al analista a
comprender el sistema a especificar.

3. Especificacin de requerimientos. Es la actividad de traducir la informacin
recopilada durante la actividad de anlisis en un documento que define un conjunto de
requerimientos. En este documento se pueden incluir dos tipos de requerimientos: los
requerimientos del usuario, que son declaraciones abstractas de los requerimientos del
cliente y del usuario final del sistema, y los requerimientos del sistema, que son una
descripcin ms detallada de la funcionalidad a proporcionar.

4. Validacin de requerimientos. Esta actividad comprueba la veracidad, consistencia y
completitud de los requerimientos. Durante este proceso, inevitablemente se descubren

errores en el documento de requerimientos. Se debe modificar entonces para corregir
estos problemas.

Por supuesto, las actividades en el proceso de requerimientos no se llevan a cabo de
forma estrictamente secuencial. El anlisis de requerimientos contina durante la
definicin y especificacin, y a lo largo del proceso surgen nuevos requerimientos. Por lo
tanto, las actividades de anlisis, definicin y especificacin se entrelazan. En los
mtodos giles como la programacin extrema, los requerimientos se desarrollan de
forma incremental conforme a las prioridades del usuario, y la obtencin de
requerimientos viene de los usuarios que forman parte del equipo de desarrollo.

2.3.2. Anlisis de restricciones

Las restricciones son relaciones entre entidades de un modelo de objetos, el trmino de
entidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restriccin
reduce los valores que una entidad puede tomar.

Restricciones entre objetos. Determina el estado en el cual los objetos se
diferencian uno al otro, ejemplo: Horario de entrada de un empleado de oficina no
puede ser despus de las 9:00, suponiendo que el horario de entrada al trabajo es
a las 9:00.
Restricciones entre atributos de un objeto: Determina los atributos especficos de
un objeto, ejemplo: El objeto alumno solo debe tener como atributos, nombre
completo y no apellido paterno, apellido materno y nombre.
Restricciones sobre un objeto a lo largo del tiempo. Determina el estado del objeto
donde especifica que nunca debe de cambiar su estado, ejemplo: El objeto alumno
no puede aumentar su nmero de control.

Las restricciones simples pueden situarse en el modelo de objetos, restricciones
complejas aparecern en el modelo funcional. Las restricciones no tienen por qu
aparecer inicialmente en el modelo de objetos, estas irn aadindose conforme se vaya
concretando en la definicin del modelo.



Actividad 2. Requerimientos, fases y restricciones para disear un
programa

Con el fin de aplicar cada uno de los conceptos bsicos de los estndares de
especificaciones de un anlisis, disea un programa con orientacin a objetos haciendo
un documento que sirva como base para conocer los requerimientos para disear un
programa para un saln de belleza.

1. Plantea una situacin hipottica o ve a preguntar a un saln de belleza con el
encargado o encargada acerca de qu le gustara controlar por computadora (Obtencin y
anlisis de requerimientos).

2. En un archivo de texto escribe los requerimientos del usuario y del sistema, de
acuerdo a lo recabado en la entrevista (Especificacin de requerimientos).

3. Apunta si es viable o no (Validacin de requerimientos).

4. Guarda la Actividad con el nombre DOO_U2_A2_XXYZ. Donde XX son es apellido(s) y
YY nombre(s).


2.4. Modelos del desarrollo del software

Las metodologas se centra en una serie de combinaciones de los modelos de proceso
genricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodologa debe
definir con precisin los roles y actividades involucradas, junto con prcticas, guas de
adaptacin.

Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas
asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo,
por ejemplo, suele hablarse de mtodos de anlisis y/o diseo.

La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la
diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y
alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones
utilizadas para especificar artefactos producidos en actividades de anlisis y diseo,

podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y
Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de
desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del
proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de
Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o
Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms
orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a
equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos
asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la
Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas primero
para el Diseo (por ejemplo: el diagrama de Estructura) y posteriormente para el Anlisis
(por ejemplo: Diagramas de Flujo de Datos). Estas metodologas son particularmente
apropiadas en proyectos que utilizan para la implementacin lenguajes de 3ra y 4ta
generacin.

Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE (Francia),
MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de propuestas de mtodos
estructurados en el mbito acadmico: Gane &Sarson, Ward &Mellor, Yourdon&DeMarco
e InformationEngineering.

Metodologas orientadas a objetos, va unida a la evolucin de los lenguajes de
programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a
fines de los 70s Smalltalk-80, la primera versin de C++ por BjarneStroustrup en 1981 y
actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a consolidarse
algunos mtodos Orientados a Objeto

En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de
conseguir una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a
un objetivo ms modesto, para dar lugar al UnifiedModelingLanguage (UML), la notacin
OO ms popular en la actualidad (Booch-Grady, 1996)).

Algunos mtodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE
(Jacobson), Coad&Yourdon, Shaler&Mellor y OMT (Rumbaugh).

Algunas metodologas orientadas a objetos que utilizan la notacin UML son:
RationalUnifiedProcess (RUP), OPEN, MTRICA (que tambin soporta la notacin
estructurada).


2.4.1. giles

Nuevas tcnicas para aplicar las prcticas esenciales de la programacin extrema y
mtodos giles para desarrollar sistemas orientados a objetos se encuentre la
metodologa gil. Es cuando el desarrollo de software es incremental (entregas pequeas
de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil
de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de
ltimo momento)

El modelado gil tambin abarca un conjunto de principios esenciales. Adems delos
principios esenciales de la programacin extrema, el modelado gil agrega principios tales
como "modelar con un propsito", "el software es su meta principal" y "viajar con poco
equipaje", una forma de decir que poca documentacin es suficiente.

Entre las metodologas giles identificadas:
Extreme Programming
Scrum
Familia de Metodologas Crystal
Feature Driven Development
ProcesoUnificado Rational, unaconfiguracingil
Dynamic Systems Development Method
Adaptive Software Development
Open Source Software Development

2.4.2. Predictivos

Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin
durante todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o
clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin
del sistema.

Todas las propuestas metodolgicas antes indicadas pueden considerarse como
metodologas tradicionales por el especial nfasis que presenta en cuanto a su
adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse),
realizando una configuracin adecuada, podra considerarse gil.

La inspiracin usual para las metodologas han sido disciplinas como las ingenieras civil o
mecnica. Tales disciplinas enfatizan que hay que planear antes de construir. Los
ingenieros trabajan sobre una serie de esquemas que indican precisamente qu hay que

construir y cmo deben juntarse estas cosas. Muchas decisiones de diseo, como la
manera de controlar la carga sobre un puente, se toman conforme los dibujos se
producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una
compaa diferente, para ser construidos. Se supone que el proceso de la construccin
seguir los dibujos. En la prctica los constructores se encuentran con algunos
problemas, pero stos son normalmente poco importantes.

Como los dibujos especifican las piezas y cmo deben unirse, actan como los
fundamentos de un plan de construccin detallado. Dicho plan define las tareas que
necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un
plan de trabajo y un presupuesto de construccin razonablemente predecibles. Tambin
dice en detalle cmo deben hacer su trabajo las personas que participan en la
construccin. Esto permite que la construccin requiera menos pericia intelectual, aunque
se necesita a menudo mucha habilidad manual.

As que lo que vemos aqu son dos actividades fundamentalmente diferentes. El diseo,
que es difcil de predecir y requiere personal caro y creativo, y la construccin que es ms
fcil de predecir. Una vez que tenemos el diseo, podemos planear la construccin. Una
vez que tenemos el plan de construccin, podemos ocuparnos de la construccin de una
manera ms predecible. En ingeniera civil la construccin es mucho ms costosa y
tardada que el diseo y la planeacin.

As el acercamiento de muchas metodologas es: queremos un plan de trabajo predecible
que pueda usar gente del ms bajo nivel. Para hacerlo debemos separar el plan de la
construccin. Por consiguiente necesitamos entender cmo hacer el diseo de software
de modo que la construccin pueda ser sencilla una vez que el plan est hecho.

Qu forma toma este plan? Para muchos, ste es el papel de notaciones de diseo
como el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones
significativas usando UML, podemos armar un plan de construccin y entonces podemos
dar planes a los programadores como una actividad de construccin.

Pero aqu surgen preguntas cruciales. Es posible armar un plan que sea capaz de
convertir el cdigo en una actividad de construccin predecible? Y en tal caso, es la
construccin suficientemente grande en costo y tiempo para hacer valer la pena este
enfoque?

Todo esto trae a la mente ms preguntas. La primera es la cuestin de cun difcil es
conseguir un diseo UML en un estado que pueda entregarse a los programadores. El
problema con un diseo tipo UML es que puede parecer muy bueno en el papel, pero
resultar seriamente fallido a la hora de la programacin. Los modelos que los ingenieros
civiles usan estn basados en muchos aos de prctica guardados en cdigos

ingenieriles. Adems los problemas importantes, como el modo en que juegan las fuerzas,
son dciles al anlisis matemtico. La nica verificacin que podemos hacer con los
diagramas UML es la revisin cuidadosa. Mientras esto es til trae errores al diseo que
slo se descubren durante la codificacin y pruebas. Incluso los diseadores
experimentados se sorprenden a menudo cuando convierten dichos diseos en software.

Otro problema es el costo comparativo. Cuando se construye un puente, el costo del
esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construccin.
En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Se
sugiere que para un proyecto grande, slo 15% del proyecto son cdigo y pruebas
unitarias, una inversin casi perfecta de las proporciones de la construccin del puente.
Aun cuando se consideren las pruebas parte de la construccin, el plan es todava 50%
del total. Esto genera una pregunta importante sobre la naturaleza del diseo en software
comparado con su papel en otras ramas de la ingeniera.

Actividad 3. Cuadro Comparativo de modelos giles y predictivos

1. En un archivo de texto, realiza un cuadro comparativo de los modelos giles y
predictivos, teniendo en cuenta las definiciones vistas en los temas anteriores.

Ejemplo:

2. Guarda la actividad con el nombre DOO_U2_A3_XXYZ.Donde XX es tu apellido(s) y
YY nombre(s).




Autoevaluacin

primera unidad del curso, es necesario que resuelvas la actividad integradora. Recuerda
que es muy importante leer cuidadosamente los planteamientos indicados y elegir la
opcin adecuada para cada uno.

Evidencia de aprendizaje. Requerimientos para disear un programa
Orientado a Objetos

Como parte de la evaluacin de esta unidad, debes llevar a cabo una actividad cuyo
propsito es conceptuar el proceso.

1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con los
estndares para disear un programa con OO para el control de una papelera y
menciona el modelo de software a aplicar en la misma.

2. Dale formato.

3. Guarda la evidencia con el nombre DOO_U1_EA_XXYZ.


Cierre de la unidad

Has concluido la unidad 2 del curso a lo largo de esta trabajaste con la documentacin de
requerimientos para el anlisis orientado a objetos, comenzando con la parte de
levantamiento de requerimientos, que incluye el describir cules son los requerimientos y
que actividades necesitas realizar para el levantamiento de los mismos.

Tambin identificas cual es la documentacin para el levantamiento y que
especificaciones debe cumplir considerando sus estndares, divididos en sus fases y
anlisis de restricciones. Por ltimo en esta unidad debes distinguir que modelos del
desarrollo de software se manejan y si son giles o predictivos.


acaban de mencionar no te sean familiares o no los recuerdes, de no ser este t caso, ya
ests preparado(a) para seguir con la unidad 3, en donde continuars con la
Metodologas de Diseo para la Generacin de Sistemas Orientados a Objetos, tales
como Bosh, OOC, OMT y UML. Todo ello con el fin de terminar la ltima unidad del curso
de Anlisis y Diseo Orientado a Objetos.

Fuentes de consulta

Booch-Grady (1996) Anlisis y Diseo Orientado a Objetos con aplicaciones. Mxico:
Pearson Educacin.
Cueva, J. (2005) Ingeniera del Software. Madrid: Pearson Educacin.
Cueva, J. (2005) Anlisis orientado a objetos, en:El proceso de desarrollo de
software. Recuperado el 22 de julio de 2011 de:
http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf
Fowler, M. (2003) La nueva metodologa. Traduccin de Alejandro Sierra para
programacionextrema.org. Recuperado el 22 de julio de 2011 de:
http://www.programacionextrema.org/articulos/newMethodology.es.html
Garca, S. y Morales, E. (2003) Desarrollo de aplicaciones informticas. Anlisis y
diseo detallado de aplicaciones informticas de gestin. Mxico: Ed. Thompson.
Kendall, E. (2005) Anlisis y Diseo de sistemas. Mxico: Pearson Educacin.
Letelier, P. y Penads, M. (s/f) Metodologas giles para el desarrollo de software:
eXtremeProgramming (XP). Universidad Politcnica de Valencia. Recuperado el 22
de julio de 2011 de: http://www.willydev.net/descargas/masyxp.pdf
WorldLingo (2011) Anlisis de requisitos. WorldLingoTranslations LLC. Recuperado el
22 de julio de 2011 de:
http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis



Unidad 3. Metodologas de diseo para la generacin de sistemas
orientados a objetos


En las metodologas de anlisis y diseo orientado a objetos, se utilizan algunos
conceptos que se definen a continuacin.

Mtodo. Es un conjunto de lineamientos y reglas, incluyendo los siguientes
componentes.
Conceptos de modelado. Permiten la captura de la semntica y el conocimiento
acerca de un problema y su solucin.
Modelo es una representacin formal de un sistema con cierto nivel de
abstraccin. En las etapas de especificacin de requerimientos y anlisis el nivel
de abstraccin normalmente es alto, omitiendo detalles de implementacin.
Meta modelo. Es un modelo que describe otros modelos, describe los conceptos
del mtodo modelo y sus relaciones, define los modelos legales que pueden ser
construidos dentro del mtodo, describe la informacin que debe ser capturada.
Vistas y notaciones. Son tiles en la presentacin fundamental del modelo de
informacin para que los seres humanos puedan comprenderla, examinarla y
modificarla en su caso.
Una vista solo muestra una parte de la semntica del modelo y diferentes vistas
pueden presentar la misma informacin en varias formas.
Notacin. Permite construir, examinar y manipular modelos, el mismo modelo se
puede dibujar de diferentes maneras mediante el uso de diferentes smbolos,
donde algunos de ellos pueden tener el mismo significado. Cada persona puede
adoptar su propio formato para describir sus diagramas.
Proceso de desarrollo iterativo. Representa una secuencia de pasos para la
construccin e implementacin de modelos. El proceso puede estar distribuido en
varios niveles de detalle, desde el nivel ms alto del proyecto, hasta etapas
especficas para la construccin de modelos de bajo nivel. El proceso indica qu
modelos se debern construir y cmo construirlos.
Proceso. Es la gua que indica como producir un modelo, proporciona un esqueleto
de trabajo (frameworks) para el desarrollo, describe los artefactos a ser producidos
y las etapas para producirlos. A alto nivel, describe el desarrollo del ciclo de vida y
las etapas de iteracin dentro de l. A bajo nivel describe un esqueleto de trabajo
para la produccin de modelos; las etapas para la construccin del modelo,
lineamientos para describir componentes de l, principios de diseo a seguirse,

mediciones de calidad, referencias cruzadas, reglas de consistencia y banderas
rojas para identificar posibles problemas.
Patrn. Es una solucin estndar escrita para resolver un problema, basada en
una secuencia de tiempo. No existen museos de programas donde los nuevos
diseadores puedan aprender, emulando programas que all existen, mas bien,
tratan de captar ideas de los diseadores expertos. Actualmente existe un
Movimiento de Patrones con el propsito de coleccionar, catalogar y explicar
patrones tiles de diseo, de tal forma que otros diseadores puedan aprender de
ellos. Por lo tanto, Los Patrones son resmenes de casos de diseo basados en la
experiencia.
Reglas de Diseo. Son estados o propiedades que debern llevarse a cabo u
omitirse en un diseo o estrategias generales de diseo a utilizar. Tips y Reglas de
dedo. Son recomendaciones que se aplican donde sea necesario, no se organizan
en etapas. Son presentaciones informales de patrones.

En los mtodos AOO/DOO existen dos tipos principales, dividiendo a estos en:

Estticos (enfocados a datos), lo importante es la estructura de datos anexa a los
objetos y las operaciones que sobre ella operan.
Dinmicos (enfocados a comportamientos o enfocados a responsabilidades): un
objeto tiene sentido en estos mtodos cuando exhibe un comportamiento
diferencial respecto del resto delos objetos.



En la tabla anterior se mezclan mtodos de anlisis y de diseo porque, pese a lo que
anuncien sus autores o aun su mismo nombre, la distincin entre anlisis y diseo se
difumina, aqu presentamos los ms utilizados y que dieron origen al que actualmente se
utiliza para el ADOO.

Propsito

Con el transcurso de esta unidad ubicars las diferentes metodologas para el diseo de
sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /
Ingeniera de software orientado a objetos), OMT (Object Modeling Technique / Tcnica
de modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado de
Modelado) las cuales nos servirn despus de hacer un anlisis para hacer un buen
diseo apoyado con estas tcnicas.



Comparar las metodologas de diseo para la generacin de sistemas orientados a
objetos mediante los diagramas con los mtodos de modelado Booch, OOSE, OMTy
UML.

3.1. Booch

Es una metodologa que se utiliza en el anlisis y diseo de software creada por Booch
durante su estancia en Rational Software Corporation.

El mtodo BOOCH define modelos para describir un sistema, soportando el desarrollo
iterativo e incremental. El mtodo incluye diferentes diagramas segn el enfoque que se
le d ya sea:
De clases
De objetos
De transicin de estados
De mdulos
De procesos
De interaccin

3.1.1. Introduccin

El mtodo cuenta con una notacin expresiva y bien definida que le permite al diseador
expresar sus ideas y concentrarse en problemas ms serios.

Son necesarias dos dimensiones para especificar la estructura y comportamiento de un
sistema orientado a objetos:

Dimensin uno: Fsica / Lgica.
Dimensin dos: Esttica / Dinmica.

Para cada dimensin se definen una serie de diagramas que denotan una vista de los
modelos del sistema, stos reflejan "toda la verdad" sobre sus clases, relaciones y otras
entidades y cada diagrama representa una proyeccin de estos modelos. En el estado
estable, todos estos diagramas deben ser consistentes con el modelo y tambin
consistentes entre ellos mismos.


Dimensin lgica: Describe la existencia y significado de las abstracciones principales y
los mecanismos que forman el espacio del problema o para definir la arquitectura del
sistema.

Dimensin fsica: Describe la composicin concreta en cuanto a hardware y software del
contexto o implantacin del sistema.

Dimensin esttica: Estn formados por los diagramas de:

1.- Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visin
lgica de un sistema, utilizada en la etapa de anlisis.
2.- Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa
de diseo lgico de un sistema.
3.- Diagramas de mdulos: Muestran la asignacin de clases y objetos a mdulos en el
diseo fsico de un sistema.
4.- Diagramas de procesos: Muestran la asignacin de procesos a procesadores en el
diseo fsico de un sistema.

Dimensin dinmica: La semntica dinmica de un problema se expresa mediante los
siguientes diagramas:

1.-Diagrama de transicin de estados: Muestra el comportamiento de cada instancia de
una clase, los eventos que provocan una transicin de un estado a otro y las acciones que
resultan de este cambio de estado, por lo que, cada clase puede contar con este tipo de
diagrama.
2.- Diagramas de interaccin: Muestra el orden temporal en que se suceden los mensajes
en un conjunto de objetos que representan un escenario. Estn en el mismo contexto que
los diagramas de objetos.

3.1.2. Modelos

Diagramas de Clases

Un diagrama de clases es utilizado para mostrar la existencia de clases y sus relaciones
en la visin lgica de un sistema. Los dos elementos esenciales de un diagrama de clases
son: las clases y sus relaciones bsicas.


La figura siguiente muestra el icono que se utiliza para representar una clase en un
diagrama de clases. En ciertos diagramas de clases, es til exponer algunos de los
atributos y operaciones asociados con una clase:

Figura 3.1. Clase

Los atributos denotan una parte de un objeto agregado, durante el diseo expresan una
propiedad singular de la clase.
A Nombre del atributo solamente.
C Clase del atributo solamente.
A:C Nombre y clase del atributo.

Las operaciones denotan algn servicio proporcionado por la clase, se distinguen de los
atributos aadiendo parntesis.
N() Nombre de la operacin solamente.
R N(Argumento) Clase de retorno de la operacin, nombre y parmetros formales (si los
hay).

Las relaciones de clase representan una colaboracin con otras clases de diversas
maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones:

Figura 3.2. Conexiones entre clases


La asociacin conecta dos clases y denota una conexin semntica, se etiquetan con
expresiones sustantivas, denotando la naturaleza de la relacin.

La herencia denota una relacin de generalizacin / especializacin (una relacin <<es
un>>), y aparece como una asociacin con una cabeza de flecha. La flecha apunta a la
superclase, y el extremo opuesto de la asociacin designa la subclase. La subclase
hereda la estructura y comportamiento de su superclase. Las relaciones de herencia no
pueden llevar indicaciones de cardinalidad.

La Posesin: denota una relacin todo / parte (relacin <<tiene un>> o agregacin),
aparece como una asociacin con un crculo relleno en el extremo que seala al
agregado, la clase que est en el otro extremo denota la parte cuyas instancias estn
contenidas por el objeto agregado.

La Utilizacin: denota una relacin cliente / servidor y aparece como una asociacin con
una circunferencia en el extremo que denota al cliente. En esta relacin de alguna forma
el cliente depende del servidor para que ste le proporcione determinados servicios.

Figura 3.3. Utilizacin

Diagramas de Objetos

Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones
en el diseo lgico de un sistema. Los dos elementos esenciales de un diagrama de
objetos son los objetos y sus relaciones.

Objetos en la figura siguiente muestra el icono que se usa para representar un objeto en
un diagrama de objetos. Al igual que en el diagrama de clases, tambin se pueden
especificar algunos atributos del objeto.



Figura 3.4. Objeto

Relaciones entre objetos: los objetos interaccionan a travs de sus enlaces con otros
objetos, un enlace es una instancia de una asociacin, al igual que un objeto es una
instancia de una clase.

Figura 3.5. Relaciones entre objetos

Flujo de datos: los datos pueden fluir en la misma direccin que un mensaje o en
direccin contraria. El mostrar explcitamente la direccin del flujo de datos ayuda a
explicar la semntica de un escenario particular.

Objetos activos: son aquellos que incorporan su propio hilo de control.

Figura 3.6. Objetos activos

Diagramas de mdulos


Se utiliza un diagrama de mdulos para mostrar la asignacin de clases y objetos a
mdulos en el diseo fsico de un sistema. Un solo diagrama de mdulos representa una
vista de la estructura de mdulos de un sistema. Los dos elementos esenciales de un
diagrama de mdulos son los mdulos y sus dependencias.

Programa principal: Denota un archivo que contiene la raz del programa.

Especificacin y cuerpo: Denotan archivos que contienen la declaracin y la definicin de
las entidades.

Subsistema: Los subsistemas sirven para modularizar el modelo fsico de un sistema. Un
subsistema es un agregado que contiene otros mdulos y otros subsistemas. Cada
mdulo engloba la declaracin o definicin de clases, objetos y otros detalles del lenguaje.

Dependencias: la nica relacin que puede darse entre dos mdulos es una dependencia
de compilacin, representada por una lnea dirigida que apunta al mdulo respecto al cual
existe la dependencia. Las flechas denotan dependencias, la flecha sale del el icono
dependiente.

Diagrama de procesos

Se usa un diagrama de procesos para mostrar la asignacin de procesos a procesadores
en el diseo fsico de un sistema. Un solo diagrama de procesos presenta una vista de la
estructura de procesos de un sistema.

Elementos del diagrama

Procesadores. Elemento de hardware capaz de ejecutar programas.
Dispositivos. Elemento de hardware incapaz de ejecutar un programa.
Conexiones. Son lneas no dirigidas para indicar conexiones entre procesadores y/o
dispositivos.



Figura 3.7. Diagrama de procesos

El proceso de diseo orientado a objetos no puede describirse mediante reglas, aunque
est bastante bien definido como para brindar un proceso predecible y repetible para una
organizacin de software madura.

Un proyecto de software bien hecho es aquel en el que el software entregado satisface y
posiblemente excede las expectativas del cliente. Se ha desarrollado de forma
econmica, entregado en tiempo, y es flexible al cambio y al crecimiento.

3.2. OOSE

Este mtodo fue desarrollado por Ivar Jacobson OOSE un enfoque para el manejo de
casos de uso, este modelo de casos de uso sirve como un modelo central para otros
modelos.

Este modelo es la base en la etapa de anlisis, construccin y prueba.

OOSE presenta cinco tcnicas para modelar un sistema:

Modelo de requerimientos: delimita el sistema y define su funcionalidad.
Modelo de anlisis: estructura el sistema, modelando tres tipos de objetos (objetos
de interface, objetos entidad y objetos de control).

Modelo de diseo: refina el modelo de anlisis y lo adapta a un ambiente de
implementacin. Consiste de diagramas de interaccin y diagramas de transicin
de estados.
Modelo de implementacin: consiste en el cdigo fuente de los objetos
especificados en el modelo de diseo.
Modelo de prueba: es llevado a cabo mediante la realizacin de pruebas al modelo
de implementacin.

La idea bsica de estos modelos es capturar el concepto inicial de todos los
requerimientos funcionales y usar sus perspectivas. Es por eso que la relacin entre ellos
es importante. Para ser posible el mantenimiento del sistema es tambin necesario que
los modelos sean tangibles.

3.2.1. Introduccin

Este mtodo proporciona un soporte para el diseo creativo de productos de software,
inclusive a escala industrial. El autor plantea el problema del diseo y construccin de
software haciendo una comparacin con la industria de la construccin, contemplando las
siguientes fases:

Herramientas. Soportan todos los aspectos de la empresa, explcitamente las
actividades de arquitectura, mtodos y procesos.
Procesos. Permite el escalamiento de los mtodos, de tal forma que puedan ser
aplicados a proyectos de forma interactiva y en partes.
Mtodos. Establece de manera explcita los procedimientos etapa por etapa que
deben seguirse para aplicar la arquitectura al proyecto.
Arquitectura. Una buena estructura del sistema es fcil de entender, de cambiar y
realizar pruebas y mantenimiento. Las propiedades del sistema determinan cmo
la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la
arquitectura son extremadamente importantes y forman la base del mtodo.

Diseo creativo. Las actividades creativas de un desarrollo, consisten en la
transformacin de un conjunto de requerimientos y nociones vagas, en un plan
estructurado de construccin y un plan de accin para su implementacin .El diseo
creativo tomando como referencia una base arquitectnica es seguir paso a paso los
mtodos y procesos con la asistencia de herramientas, para convertir los requerimientos
dentro de una arquitectura viable para la construccin de un proyecto incluyendo la
creacin de prototipos.


Un aspecto importante durante el desarrollo del sistema, es considerar explcitamente el
proceso de cambio.

Todos los sistemas cambian durante su ciclo de vida. Hoy en da el desarrollo de los
nuevos mtodos es conocer qu cambios son los principales en la parte global del ciclo
de vida, as como el costo del sistema. Una industrial del proceso debe por lo tanto saber
sobre los cambios del sistema. Un sistema normalmente desarrolla cambios
incorporndose en nuevas versiones.

La primera versin de un sistema representa una pequea parte de una composicin
durante el ciclo de vida del sistema.

Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva
versin de un sistema, as como para un sistema totalmente nuevo. La diferencia radica
en que las entradas para cada etapa cambian en cada ciclo de vida.

Modelo de anlisis. Especifica el comportamiento funcional del sistema bajo
prcticamente circunstancias ideales y sin hacer alusin a un ambiente particular de
implementacin.

Construccin. La primera actividad en la construccin consiste en la implementacin de
los detalles que conciernen a la arquitectura y construccin del plan, que es ir de una
mayor abstraccin a concretizar ms el plan.

Diseo. Formaliza el modelo de anlisis en trminos del ambiente de implementacin y
especifica la identidad de los bloques de construccin.

Prueba del sistema. Consiste en la verificacin del trabajo de cada uno de los paquetes
de servicio definidos en el modelo de anlisis Esta fase tiene lugar en varios niveles,
desde funciones especficas, hasta el sistema completo.

Desarrollo incremental. El desarrollo del sistema es usualmente un proceso el cual toma
varios aos para su terminacin. La especificacin es seguida por el anlisis, la
construccin y prueba del sistema completo. Este mtodo puede trabajar si todos los
requerimientos del sistema son conocidos del conjunto de salida.

En la mayora de los casos, conviene mejor desarrollar el sistema etapa por etapa,
empezando con unas cuantas funciones principales, como se va aclarando la
comprensin del sistema en cuanto a su funcionalidad se van agregando nuevas
funciones, de esta forma el sistema va creciendo.
Sistema de desarrollo y metodologa. Cuando se desarrolla un sistema grande es
importante conocer cmo cada uno de los pasos del mtodo interacta y cmo ellos

compiten dentro del desarrollo del proceso. Se hace hincapi en la discusin entre el
proceso de desarrollo y las ideas bsicas que hay detrs del mtodo lo que determina la
seleccin de una arquitectura de un universo de arquitecturas.

3.2.2. Modelos

El sistema de desarrollo es una tarea compleja. Algunos aspectos diferentes han sido
tomados en consideracin. Se trabaja con 5 modelos:

1. El modelo de requerimientos: El objetivo es la captura de requerimientos
funcionales.
2. El modelo de anlisis: El objetivo es dar al sistema una estructura de objetos
robusta y flexible a los cambios.
3. Modelo de diseo: Tiene como objetivo adoptar y refinar la estructura de objetos
en el ambiente actual de implementacin.
4. El modelo de implementacin: Tiene como objetivo implementar el sistema.
5. El modelo de prueba: Su objetivo es verificar el sistema.

La idea bsica de estos modelos es capturar el concepto inicial de todos los
requerimientos funcionales y usar sus perspectivas. Es por eso que la relacin entre ellos
es importante. Para hacer posible el mantenimiento del sistema es tambin necesario que
los modelos sean tangibles.

Modelo de requerimientos
Actores y Casos de Uso
La primera transformacin hecha de la especificacin de requerimientos para el modelo
de requerimientos consiste en:

Un modelo de caso de uso
Descripcin de la interface
Un modelo en el dominio del problema

Figura 3.8. Modelo de caso de uso


El modelo de caso de uso utiliza actores y caso de uso. Estos conceptos son usados para
definir si existe contacto externo con el sistema (actores), y qu debera ser hecho por el
sistema (caso de uso).

Los actores representan quienes interactan con el sistema. Representan todas las
necesidades de cambio de informacin con el sistema. Dado que el actor representa la
parte exterior del sistema no se describirn detalles de ellos.

La diferencia entre un actor y un usuario radica en que el usuario es la persona que usa el
sistema, mientras que el actor es un rol que el usuario puede jugar.

Modelo de anlisis

Se ha visto que el modelo de requerimientos tiene como objetivo definir las limitaciones
del sistema y especificar su comportamiento. Cuando el modelo de requerimientos ha sido
desarrollado y aprobado por los usuarios se puede iniciar el desarrollo del sistema.

La informacin para este sistema se enfoca en la captura de:

Informacin: Especifica la informacin de ayuda en el sistema. As como describe
el estado interno del sistema.
Comportamiento: Especifica el comportamiento que adopta el sistema. Especifica
cundo y cmo el sistema cambia de estado.
Presentacin: Detalla la presentacin del sistema al mundo exterior.

Figura 3.9. Dimensiones del modelo de anlisis

Existen varios tipos de objetos usados para la estructura del sistema en el modelo de
anlisis



Figura 3.10. Tipos de objeto

Cada objeto al menos captura dos de las tres dimensiones del modelo de anlisis, sin
embargo cada uno de ellos tiene cierta inclinacin hacia una de las dimensiones.

Figura 3.11. Dimensiones del modelo de anlisis

El modelo de diseo

El proceso de construccin edifica el sistema usando tanto el modelo de anlisis y el
modelo de requerimientos. Primero se crea el modelo de diseo que es un refinamiento y
formalizacin del modelo de anlisis. Al inicio del trabajo cuando se desarrolla el modelo
de diseo es para adaptarlo a la implementacin del ambiente actual.

Figura 3.12. Implementacin del ambiente

Una diferencia entre el modelo de anlisis y el modelo de diseo es que el modelo de
anlisis debe ser visto como un modelo conceptual o lgico del sistema, y el modelo de

diseo contiene el cdigo, por lo cual el modelo de diseo deber ser una representacin
de la manera como el cdigo fuente es estructurado, manejado y escrito.

Figura 3.13. Consecuencias del ambiente

El modelo de Implementacin

La implementacin del modelo consiste de la notacin del cdigo. La informacin de
espacio es la opcin del lenguaje de programacin que se usa. No necesariamente se
requiere de un lenguaje de programacin orientada a objeto, sin embargo, si se
recomienda el uso de un lenguaje de programacin orientada a objeto, desde la
concepcin inicial hasta la construccin. La base para la implementacin es el modelo de
diseo. Aqu se especifica la interface dcada bloque.

El modelo de prueba

El modelo de prueba es el ltimo modelo a construir. Describe simplemente el estado de
resultados de la prueba. El modelo de requerimientos de nuevo representa una
herramienta potente de prueba, al probar cada caso de uso, se verifica que los objetos se
comuniquen correctamente en dicho caso de uso. De manera simular se verifica la
interface de usuario, descrita en el modelo de requerimientos, con todo lo anterior, el
modelo de requerimientos es la base de verificado para el modelo de prueba.

3.3. OMT

Un modelo es una abstraccin de algo, con la finalidad de comprenderlo, antes de
construirlo, ya que un modelo omite los detalles no esenciales, es ms sencillo
manejarlos, que manejar la entidad original.

Esta tcnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos
modelo dinmico y modelo funcional.


3.3.1. Introduccin

El modelo de objetos. Es el modelo ms importante, ya que en l se identifican las clases
dentro del sistema junto con sus relaciones, as como sus atributos y operaciones, lo que
representa la estructura esttica del sistema. El modelo de objetos se representa
mediante un diagrama de clases.

El modelo dinmico. Representa los aspectos temporales de comportamiento "de control
del sistema, mediante la secuencia de operaciones en el tiempo.
El modelo funcional. Representa los aspectos transformacionales "de funcin" del
sistema, mediante la transformacin de valores de los datos. Se representa mediante un
diagrama de flujo.

Cada modelo describe un aspecto del sistema pero contiene referencias a los dems
modelos. Lo cual indica que los tres no son totalmente independientes.

Pasos del proceso de desarrollo orientado a objetos:
Conceptualizacin: Se describen los requerimientos para la solucin del sistema.
Comienza identificando las necesidades desde el punto de vista de los usuarios. Dicha
informacin puede ser extrada de los casos de uso y del dominio del problema.

Anlisis: Entender y modelar el problema en el dominio de la aplicacin.
Diseo del sistema: Determinar la arquitectura del sistema en trminos de subsistemas.
Diseo de objetos: Refinar y optimizar el modelo de anlisis, agregando conceptos de
programacin.
Cdigo: Implementar las clases de objetos en un lenguaje de programacin.
Pruebas: se realizan para verificar el comportamiento de las clases y objetos que se
encuentran descritos en los escenarios.

Figura 3.14. Proceso de desarrollo orientado a objetos

Cada paso del proceso transforma algunas entradas para generar una salida diferente,
comenzando en un alto nivel de abstraccin hasta llevarlo a un nivel de detalle que
finalmente representa la solucin del problema.



3.3.2. Modelos

Los pasos para construir el modelo de objetos son los siguientes:

1. Identificacin de objetos y/o clases.
2. Crear un diccionario de datos.
3. Identificacin de las asociaciones y agregaciones entre los objetos.
4. Identificacin de atributos y enlaces.
5. Organizacin y simplificacin de las clases empleando herencia.
6. Verificacin de las vas de acceso necesarias para llevar a cabo las probables
consultas.
7. Realizar las iteraciones necesarias para el refinamiento del modelo.
8. Agrupar las clases en mdulos.

Modelo de objetos = Diagrama de modelo de objetos + diccionario de datos.

Diagrama de clases

En l se describen las clases que se descubrieron para el sistema analizado en trminos
del dominio del problema. Adems se especifican los atributos y operaciones que
distinguen a cada una de las clases y las relaciones con las que podemos conocer su
responsabilidad en el sistema.

Figura 3.15. Nombre Clase

Dentro del diagrama de clases, una clase se representa mediante un rectngulo donde
pueden existir tres separaciones, en la primer parte se coloca el Nombre de la clase, en la
segunda y tercera parte se pueden agregar los atributos y las operaciones, pero sino se
desea agregar ninguno de ellos, es porque no son tan importantes para la comprensin
del sistema, entonces el rectngulo solo se queda con el nombre de la clase.

Modelo dinmico = Diagrama de estados + diagrama global de flujo de sucesos.
Escenario:
Es la representacin escrita de los casos de uso y de la interaccin de los actores con
ellos para especificar el propsito del sistema.



Figura 3.16. Escenario

Diagramas de estados: Relaciona sucesos y estados. Un diagrama de estados se
representa mediante estados, transiciones, condiciones y acciones.

Estados: Los estados representan las respuestas de los objetos a varios sucesos en
determinado tiempo dentro del sistema. Dicha respuesta puede cambiar el estado del
objeto. Se representan mediante cuadros redondeados que contienen un nombre.

Transiciones: Se representan mediante flechas que salen del estado receptor hasta l y
el nombre que se coloca en la flecha es el nombre del suceso que dio lugar a dicha
transicin, cada transicin que sale de un estado corresponde a un suceso distinto, lo cual
indica que no deben de existir sucesos duplicados dentro de un estado.

Condiciones: Una condicin se puede pensar como una proteccin en las transiciones,
debido a que si se cumple dicha condicin la transicin se dar y podr pasar el objeto de
un estado a otro, si dicha condicin no se cumple inclusive podra pasar a otro estado
mediante otra transicin o quedarse en el estado receptor hasta que la condicin se
cumpla.

Accin: Es una operacin que va asociada a un suceso y se representa mediante una
barra / y el nombre de la accin, despus del nombre de la transicin.

Modelo Funcional = Diagrama de flujo de datos + restricciones. Mediante el modelo
funcional se puede observar los resultados que se tienen de un clculo de valores,
especificando solamente entradas y salidas de los valores, mas no como son calculados
estos. El modelo funcional consta bsicamente de diagramas de flujo de datos. Los
diagramas de flujo de datos son grafos que muestran el flujo de valores de datos a travs
de procesos los cuales modifican dichos valores para transformarlos en otros. Los
diagramas de flujo estn compuestos de:
Procesos
Flujos de datos
Actores
Almacenes


Procesos: se representan mediante una elipse, los procesos tienen como entrada datos,
los cuales sern transformados, por lo cual un proceso es visto como un mtodo de una
operacin aplicada a una clase de objetos.

Figura 3.17. Proceso

Flujo de datos: un flujo de datos conecta la salida de un proceso a la entrada de otro. Se
representa en el diagrama por medio de una flecha, la cual puede llevar el nombre o el
tipo de dato. Adems de trasladar los datos a otros procesos, los flujos de datos pueden
usarse para copiar un valor, realizar la composicin de un agregado y as como su
inverso.

Actividad 1. Metodologa para la generacin de sistemas OO

La presente actividad tiene como propsito que reflexiones acerca de las metodologas
vistas hasta ahora cul de ellas te parece la ms adecuada a diseos orientado a objetos.

1. Retoma las lecturas de los temas 3.1. Booch, 3.2. OOSE y 3.3. OMT.

2. Identifica las metodologas y los modelos para disear con base en la Orientacin a
Objetos.

3. Ingresa al foro y genera una nueva entrada.

3.4. UML

UML es una tcnica desde en 1994 abarca aspectos de todos los mtodos de diseo los
antecesores de UML son Grady Booch, autor del mtodo Booch; James Rumbaugh, autor

del mtodo OMT e Ivar Jacobson, autor de los mtodos OOSE y Objectory. La versin 1.0
de UML fue liberada en Enero de 1997 y ha sido utilizado con xito en sistemas
construidos para toda clase de industrias alrededor del mundo: hospitales, bancos,
comunicaciones, aeronutica, finanzas, etc.

Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o ms).
Modelar sistemas orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.

3.4.1. Introduccin

El lenguaje modelado unificado (UML) provee un sistema de arquitecturas trabajando con
objetos, anlisis y diseo, con una buena consistencia del lenguaje para especificar,
visualizar, construir y documentar un sistema de software.

Esta especificacin representa la convergencia de las mejores prcticas en la tecnologa
de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos
derivado de las tres metodologas; (Booch, OMT y OOSE). Al conjuntar los mtodos de
Booch, OMT y OOSE resulta un lenguaje de modelado potente para los usuarios de stos
y otros mtodos.

El UML da la idea que lo que se est haciendo, se realiza con mtodos existentes. Los
objetivos que se fijaron al desarrollar el UML fueron los siguientes:

Proporcionar a los usuarios un Lenguaje de Modelado Visual de tal forma que sea
posible intercambiar informacin de los modelos.
Proporcionar mecanismos de extensibilidad y especializacin para ampliar los
conceptos bsicos.
Ser independiente de un lenguaje en particular y del proceso de desarrollo.
Proporcionar bases formales para la comprensin del Lenguaje de Modelado.
Integracin en una mejor prctica.

El UML es un lenguaje de modelado que incorpora a la comunidad orientada a objetos el
consenso de los conceptos de modelado bsico y permite desviaciones, las cuales se

expresan en trminos de mecanismos de extensin. Es un conjunto preciso que consiste
en la definicin de la semntica y notacin del UML, definiendo tambin cmo se maneja
el Lenguaje de Especificacin de Objetos.

Partiendo del hecho que el ser humano requiere de modelos para manejar sistemas
complejos, y en cuanto ms complejos se vuelven los sistemas, es necesario tener
mejores tcnicas de modelado. El contar con una metodologa universal para el desarrollo
de sistemas de software es de gran beneficio en la construccin de todo tipo de sistemas.
Disponer de buenos modelos facilita la comunicacin entre equipos de trabajo en un gran
proyecto.

El UML es un Lenguaje de Modelado Visual riguroso, y ya convertido en un estndar, es
la herramienta ideal para atacar el ciclo de vida de un proyecto de software utilizando la
tecnologa Orientada a Objetos.

El documento describe los mecanismos de la notacin para la representacin visual del
UML.

Existen bsicamente cuatro constructores grficos usados en la notacin del UML; iconos,
smbolos de 2 dimensiones, uniones y cadenas.

Icono. Es una figura grfica de tamao y forma definida, stos pueden aparecer dentro del
rea de los smbolos, en la terminacin de una unin, etc.
Smbolos de 2 dimensiones. Son de tamao variable, pueden contener listas de cadenas
u otros smbolos. Las uniones se conectan a los smbolos de 2 dimensiones como
terminacin de la unin sobre alguna parte del contorno de dicho smbolo.
Uniones. Son segmentos de lnea con sus extremos terminados en algn smbolo de 2
dimensiones.
Cadenas. Representan conceptos, pueden existir como un elemento dentro de un smbolo
o dentro de un compartimiento de un smbolo, como elementos de una lista, como
etiquetas de un smbolo o unin, o como un elemento estndar dentro de un diagrama.

El documento est dividido en varios captulos de acuerdo a los conceptos semnticos, o
por los diferentes tipos de diagramas. Cada captulo est subdividido por los elementos
que conforman el diagrama, y para cada elemento se cuenta con las siguientes
secciones:

El nombre de la notacin a describir
Semntica
Notacin
Mapeo
Opciones de presentacin


Cada punto cuenta con su propia descripcin:

Nombre de la notacin: Especifica el nombre de la notacin
Semntica: Es un breve resumen de la semntica para dicho elemento.
Notacin: Explica la representacin dotacional de la semntica mediante un diagrama.
Obviamente para cada caso se utilizan un diagrama diferente que proporciona la
identificacin de la semntica del grafo especificado.
Mapeo: Indica cmo la notacin puede ser representada como informacin semntica. Es
decir qu tipo de diagrama se utiliza, con cules rutas se maneja y cmo trabaja una
estructura conectada con otra estructura dentro de un mismo diagrama. Dando as el
sentido de saber interpretar la notacin que se presenta y con qu fin es utilizada.
Opciones de presentacin: Son herramientas que pueden ser utilizadas para dar ms
nfasis a la notacin cuando sta lo requiera dejndola ms completa y estructurada. En
varios elementos esta seccin no se presenta debido a que no tiene opciones de
presentacin.

3.4.2. OCL (Lenguaje de Especificaciones de Objetos)

El Lenguaje de Especificacin de Objetos (Object Constraint Language, OCL), es un
lenguaje formal para expresar restricciones libres de efectos colaterales. Los usuarios del
Lenguaje Unificado para Modelado (UML) y de otros lenguajes, pueden usar el OCL para
especificar restricciones y otras expresiones incluidas en sus modelos. El OCL tiene
caractersticas de un lenguaje de expresin, de un lenguaje de modelado y de un lenguaje
formal.

El OCL es un lenguaje de expresin puro. Por lo tanto, garantiza que una expresin OCL
no tendr efectos colaterales; no puede cambiar nada en el modelo. Esto significa que el
estado del sistema no cambiar nunca como consecuencia de una expresin OCL, aun
cuando una expresin OCL puede usarse para especificar un cambio de estado, por
ejemplo, en una post-condicin.

Todos los valores, de todos los objetos, incluyendo todos los enlaces, no cambiarn,
cuando una expresin OCL es evaluada, simplemente devuelve un valor.

El OCL no es un lenguaje de programacin, por lo tanto, no es posible escribir lgica de
programa o flujo de control en OCL. No es posible invocar procesos o activar operaciones
que no sean consultas en OCL. Dado que el OCL es un lenguaje de modelado en primer
lugar, es posible que haya cosas en l que no sean directamente ejecutables.


Como el OCL es un lenguaje de modelado, toda consideracin de implementacin est
fuera de su alcance, y no puede ser expresada en el lenguaje OCL. Conceptualmente,
cada expresin OCL es atmica. El estado de los objetos en el sistema no puede variar
durante la evaluacin.

OCL es un lenguaje formal donde todos los constructores tienen un significado
formalmente definido, la especificacin del OCL es parte del UML. El OCL no pretende
reemplazar lenguajes formales existentes como VDM y Z.

El OCL puede ser usado con distintos propsitos:

Para especificar caractersticas estticas sobre clases y tipos en un modelo de
clases.
Para especificar caractersticas estticas de tipo para Estereotipos.
Para especificar pre y post-condiciones sobre Operaciones y Mtodos.
Como lenguaje de navegacin.
Para especificar restricciones sobre operaciones:
Dentro del documento Semntica del UML, el OCL es usado en la seccin
reglas bien formuladas, como constantes estticas sobre la meta-clase en la
sintaxis abstracta. En varios lugares tambin es usado para definir
operaciones adicionales, que son tomadas en cuenta en la formacin de
reglas.

Las expresiones OCL pueden ser parte de pre-condiciones o post-condiciones, que son
Restricciones estereotipadas con pre-condition y post-condition respectivamente.

Las pre-condiciones o post-condiciones se aplican tanto a Mtodos como a Operaciones.

Actividad 2. Cuadro comparativo de las diferentes metodologas

La presente actividad tiene la finalidad de que apliques cada uno de los conceptos
bsicos de las metodologas de diseo vistas hasta ahora y adems, que investigues las
fechas en las que implementaron dichas metodologas.

1. Investiga las fechas en que fueron implementadas las metodologas OO.

2. En un archivo de texto, elabora un cuadro comparativo donde incluyas las
caractersticas de cada una de las metodologas OO y la fecha en que fueron
implementadas.


3. Guarda la Actividad con el nombre ADOO_U3_A2_XXYZ donde XX es apellido(s) .y
YY es tu nombre(s).


Autoevaluacin

unidad 3 del curso, es necesario que resuelvas la autoevaluacin. Recuerda que es muy
importante leer cuidadosamente los planteamientos indicados y elegir la opcin adecuada
para cada uno.

Evidencia de aprendizaje. Cuadro comparativo de los mtodos de
modelado

Como parte de la evaluacin de esta unidad, lleva a cabo la siguiente actividad cuyo
propsito es conceptuar el proceso.

1. En un archivo de texto elabora un cuadro comparativo de los diagramas que son
utilizados en cada uno de los modelos revisados en a lo largo de la unidad.

2. Al final del documento, redacta una conclusin donde expreses cules seran los
modelos ms adecuados a utilizar en cada caso.

3. Consulta la Escala de Evaluacin.

4. Guarda la evidencia con el nombre DOO_U3_EA_XXYY donde XX es tu apellido(s) y
YY tu nombre(s).


* Recuerda que de ser necesario y en base a los comentarios hechos por parte de tu
Facilitador(a), podrs enviar una segunda versin de tu actividad.



Autorreflexiones

presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado
Autorreflexiones.

Cierre de la unidad

Has concluido la unidad 3 del curso. A lo largo de sta se recordaron las metodologas de
diseo para la generacin de Sistemas Orientados a Objetos, tales como: Boosh, OOSE,
OMT, en cada uno de ellos se vio una breve introduccin y su modelo. Por ltimo el origen
de la metodologa UML, la cual fue a travs del OCL.

acaban de mencionar no te sean familiares, o no los recuerdes, de no ser este tu caso, ya
ests preparado(a) para seguir con la unidad 4, en donde continuars con El diseo
orientado a objetos con UML, a travs de la representacin de objetos y clases con
diagramas y documentacin para el diseo del software con UML, en dichos diagramas se
manejarn casos de uso, escenarios del caso de uso, diagramas de actividades,
secuencial, de clase y de grfico de estado. Todo ello con el fin de obtener el prototipo
final al terminar el curso de Anlisis y Diseo Orientado a Objetos.

Para saber ms

En el siguiente documento encontrars un ejemplo real de anlisis aplicado al diseo de
un sistema escolar:

Desarrollo de un sistema de administracin escolar acadmica para la escuela
Cristbal Coln bajo plataforma web:
http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf



Fuentes de consulta

Booch-Grady (2009) Anlisis y Diseo Orientado a Objetos con aplicaciones.
Fowler, M. & Scott, K. (1999) UML GOTA A GOTA Mxico: Addison Wesley
Graham, I. (2002) Mtodos Orientados a Objetos Mxico: Addison Wesley/Daz de
Santos.
Jacobson, I. (1992) Object-Oriented Software Engineering A Use Case Driven
Aproach Mxico: Addison-Wesley
James, R., Blaha, M., Premerlani, W. & Eddym, F. (1990) Object Oriented
Modeling and Design. Mxico: Pretice Hall.
Larman, C. (2004) Applying UML and Patterns An Introduction to object-Oriented
Analysis and Design Mxico: Prentice Hall
Martin, J. & Odell, J. (1990) Anlisis y Diseo Orientado a Objetos Mxico:
Prentice Hall Iberoamericana.
Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML
Mxico: Addison Wesley
Wirfs, R. & Wiener, L. (1990). Designing Object Oriented Softwarem. Mxico:
Pretince Hall.


Unidad 4. Diseo orientado a objetos con UML (Lenguaje Unificado de
Modelado)


El lenguaje unificado de modelado (UML) brinda un sistema de trabajo con objetos,
basado en el anlisis y diseo, con una consistencia del lenguaje para especificar,
construir y documentar un sistema de software.

Esta especificacin representa la convergencia de las mejores prcticas en la tecnologa
de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos
derivado de las tres metodologas (Booch, OMT y OOSE).

El UML es un lenguaje de modelado que integra a la comunidad orientada a objetos los
conceptos de modelado bsico y permite desviaciones, las cuales se expresan en
trminos de mecanismos de extensin. Es un conjunto preciso que consiste en la
definicin de la semntica y notacin del UML, definiendo tambin cmo se maneja el
Lenguaje de Especificacin de Objetos.

Propsito

Con el uso constante de UML se podr lograr una mejor comprensin entre los negocios y
los requerimientos del sistema y los procesos que se deben hacer para que se cumplan
stos. En cada paso el sistema se define de manera ms clara y precisa.

As, al terminar el anlisis y diseo se tienen de forma precisa y detallada las
especificaciones de clases y objetos, evitando el costo de una mala planeacin en el
comienzo.


Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos mediante el
mtodo de modelado UML.



4.1. Representacin de objetos y clases con UML

En el diseo orientado a objetos todo se presenta travs de objetos y clases. Por lo
general cuando se disea una clase no es necesario mostrar todos los atributos ni todas
sus operaciones, basta con mostrar los subconjuntos ms relevantes para organizarlos.

Un objeto, como recordars, es la unidad mnima en la representacin de algo real, y una
clase es un objeto con atributos y mtodos o comportamientos.

4.1.1. Representacin de clases con UML

Clases. Una clase es representada por medio de un marco subdividido en tres niveles: En
el primer nivel se muestra el nombre de la clase, el siguiente presenta los atributos y en el
ltimo nivel se incluyen las operaciones.

Una clase puede representarse de forma esquemtica con los atributos y operaciones
suprimidos, siendo entonces tan solo un rectngulo con el nombre de la clase. En la
siguiente figura se ve cmo una misma clase puede representarse a distinto nivel de
detalle, segn interese, y segn la fase en la que se est.



Figura 4.1. Representacion de clases con diferentes tipos de detalles

4.1.2. Representacin de objetos con UML

Objetos. El objeto es representado de forma similar que una clase. En la parte superior
del marco aparece el nombre del objeto junto con el nombre de la clase, subrayados.

El siguiente ejemplo muestra la sintaxis: nombre_del_objeto: nombre_de_la_clase. Puede
representarse un objeto sin un nombre especfico, entonces slo aparece el nombre de la
clase.


Figura 4.2. Representacin de objeto sin nombre

Actividad 1. Representacin de clases y objetos con UML

Con el fin de reflexionar sobre la asignatura, en el foro: Cmo representar clases y
objetos con UML construirs un concepto propio sobre la mejor manera de representar
clases y objetos con UML, tomando en cuenta los temas abordados con anterioridad y los
comentarios de tus compaeros.

1. Recupera lo sustancial de las lecturas del tema 4.1. Representacin de objetos y
clases con UML.

2. Identifica la forma ms ptima para representar diferentes objetos dados por tu
Facilitador(a).

3. Ingresa al foro y genera una nueva entrada.



4.2. Diagramas y documentacin para el diseo del software con UML

Los diagramas se utilizan para representar diferentes perspectivas de un sistema, de
forma que un diagrama es una proyeccin del propio sistema

El diseo de modelado UML proporciona un amplio conjunto de diagramas que
normalmente se usan en pequeos subconjuntos para poder representar las vistas
principales de la arquitectura de un sistema.

Los seis diagramas de UML que ms se utilizan son:

1. Diagrama de caso de uso: describe cmo se usa el sistema; es ideal para comenzar.
2. Escenario de caso de uso (aunque tcnicamente no es un diagrama), es una
descripcin verbal de las excepciones.
3. Diagrama de actividades, muestra el recorrido de las actividades.
4. Diagramas de secuencias, muestran el orden de actividades y las relaciones de las
clases.
5. Diagramas de clases, muestran las clases y las relaciones.
6. Diagramas de grfico de estado, muestra las transiciones de estado. Cada clase podra
crear un diagrama de grfico de estado.

La siguiente figura muestra cmo se relacionan:



Figura 4.3. Conjunto de diagramas UML (Kendall & Kendall, 2005: 665)

4.2.1. Casos de uso

Un Diagrama de casos de uso muestra la relacin entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interaccin externa.

El caso de uso es la descripcin de las secuencias de acciones recprocas entre dos o
ms objetos que se producen entre un actor y el sistema, cuando el actor usa el sistema
para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y
se representa en el Diagrama de casos de uso mediante una elipse con el nombre del
caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que
el actor desea llevar a cabo usando el sistema.

Los casos de uso son la parte realmente til del documento que describe el caso de uso,
ya que en este documento se explica la forma de interactuar entre el sistema y el usuario.


En los casos de uso, la palabra uso se utiliza como sustantivo en lugar de verbo. Un
modelo de caso de uso muestra lo que hace un sistema sin describir cmo lo hace,
muestra como si tuviera un usuario fuera del sistema, mostrando los requerimientos y se
puede hacer usando los objetos y sus interacciones para derivar comportamiento del
objeto, atributos y relaciones.

Los actores dentro del modelado UML son aquellos que interactan con el sistema a
desarrollar. Las precondiciones son los hechos que se han de cumplir para que el flujo de
evento se pueda llevar a cabo. El flujo de eventos corresponde a la ejecucin normal y
exitosa del caso de uso. Los flujos alternativos son los que permiten indicar qu es lo que
hace el sistema en los casos menos frecuentes e inesperados. Por ltimo, las
poscondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha
ejecutado correctamente.

El diagrama de caso de uso contiene el actor y smbolos de caso de uso, y adems las
lneas de conexin. Los actores se refieren a una situacin de un usuario del sistema, por
ejemplo un actor podra ser cliente.

Los actores dan o reciben los datos del sistema. Los actores secundarios ayudan a
mantener el sistema en ejecucin o proporcionan ayuda, como las personas que operan
el centro de atencin telefnica, los empleados(as) de ventanilla, etctera.

Un caso de uso ilustra a los desarrolladores un panorama de lo que quieren los usuarios.
No tiene detalles tcnicos o de implementacin.

Un caso de uso se compone de tres elementos: un actor, para comenzar el evento; el
evento, que activa un caso de uso; y el caso de uso, que desempea las acciones
activadas por el evento.

Los casos de uso documentan un solo evento. Un caso de uso se nombra con un verbo y
un sustantivo. Las relaciones son el comportamiento y se usan para conectar a un actor,
y hay cuatro tipos bsicos:

En la imagen, por el tipo de flechas, se muestran los cuatro tipos: Comunica, Incluye,
Extiende y Generaliza.

Al hacer el diagrama del caso de uso hay que pedir todo lo que los usuarios quieren que
el sistema haga para ellos, es decir, mostrar los servicios que se deben proporcionar.
En las fases iniciales sta podra ser una lista parcial que se extiende en las ltimas fases
del anlisis. Usa los siguientes lineamientos:
Revisar las especificaciones para establecer los actores.
Identificar los eventos y hacer los casos de uso.
Revisar el caso de uso para determinar el flujo de los datos.



Figura 4.4. Ejemplo de caso de uso de matriculacin de estudiante (Kendall & Kendall,
2005: 669)

La figura muestra un caso de uso de una matriculacin de un estudiante. Agregar un
estudiante incluye verificar la identidad de ste.

El caso de uso Comprar libro de texto extiende el caso de uso Matricularse en la clase y
podra ser parte de un sistema para matricular a los estudiantes de un curso en lnea.

Pareciera como si el caso de uso Cambiar informacin del estudiante fuera una
caracterstica menor del sistema y no se debiera incluir en el diagrama de caso de uso,
pero debido a que esta informacin cambia con frecuencia, la administracin tiene un
inters sutil en permitir a los estudiantes cambiar su propia informacin personal. El hecho

de que los administradores juzguen esto como importante no solo justifica, sino que exige
que el estudiante pueda cambiar su informacin.

A los estudiantes no se les permitira cambiar su promedio de calificaciones, cuotas a
pagar y otra informacin. Este caso de uso tambin incluye el caso de uso Verificar
identidad, y en esta situacin, significa que el estudiante tiene que introducir una clave de
usuario y contrasea antes de acceder al sistema. Ver informacin del estudiante permite
a los estudiantes visualizar su informacin personal, as como tambin los cursos y
calificaciones.

Los diagramas de caso de uso son un buen punto de partida, pero se necesita una
descripcin ms completa de ellos para su documentacin.

Figura 4.5. Cuatro tipos de relaciones (Kendall & Kendall, 2005: 667)


4.2.2. Escenarios del caso de uso

Cada caso de uso tiene una descripcin como escenario del caso de uso, el cual
representa un caso en el que hay flujo de eventos y rutas para el comportamiento.
No hay un formato establecido, pero se deben considerar tres puntos importantes:
1. Identificadores e iniciadores de caso de uso.
2. Pasos desempeados.
3. Condiciones, suposiciones y preguntas.
Este podra ser el caso de uso (use case) de escribir un mensaje en un foro.
Nombre: Crear mensaje foro
Autor: Juan Prez
Fecha: 28/03/2011
Descripcin:
Permite crear un mensaje en el foro de discusin.
Actores:
Usuario de Internet firmado.
Precondiciones:
El usuario debe haberse firmado en el sistema.
Flujo Normal:
1. El actor pulsa sobre el botn para crear un nuevo mensaje.
2. El sistema muestra una caja de texto para introducir el ttulo del mensaje y una
zona de mayor tamao para introducir el cuerpo del mensaje.
3. El actor introduce el ttulo del mensaje y el cuerpo del mismo.
4. El sistema comprueba la validez de los datos y los almacena.
Flujo Alternativo:
1. El sistema comprueba la validez de los datos, si los datos no son correctos, se
avisa al actor de ello permitindole que los corrija.

Poscondiciones:
El mensaje ha sido almacenado en el sistema.
Ejemplo de caso de uso (Gracia, J., 2003: 1)

Un escenario del caso de uso, es una instancia expresada en el caso de uso.

Figura 4.6. Escenario de caso de uso

4.2.3. Diagramas de actividades

Son un tipo especial de diagramas de estado que se centra en mostrar el flujo de
actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinmica
de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el
flujo de control entre objetos.

Un diagrama de actividades muestra el flujo de actividades. Las actividades producen
finalmente alguna accin, que est compuesta de ejecutables que producen un cambio en
el estado del sistema o la devolucin de un valor. Las acciones incluyen llamadas a otras
operaciones, envo de seales, creacin o destruccin de objetos, o simples clculos
(como la evaluacin de una expresin).

Grficamente, un diagrama de actividades es una coleccin de nodos y arcos.

Bsicamente un diagrama de actividades contiene:

Estados de actividad. La representacin de este estado est basada en un
rectngulo con las puntas redondeadas, donde el interior se representa una
actividad. El estado de actividad puede descomponerse en ms sub-actividades
representadas a travs de otros diagramas de actividades, estos estados pueden
ser interrumpidos y pueden tardar cierto tiempo en concluir. Adicional se pueden
encontrar elementos como: acciones de entrada y acciones de salida, tal como se
muestra en el ejemplo siguiente.



Figura 4.7 Diagrama de actividades para modelar una actividad (Alarcn, 2005: 73)

Estados de accin. Al igual que el estado de actividad, el estado de accin, est
basado en un rectngulo con las puntas redondeadas, donde en el interior se
representa una accin.

Transiciones. Las transiciones muestran el paso de un estado a otro, bien sea
estado de actividad o de accin. Esta transicin se produce como resultado de la
finalizacin del estado del que parte el arco dirigido que marca la transicin. Como
todo flujo de control debe empezar y terminar en algn momento, se puede indicar
esto utilizando dos disparadores de inicio y final.

Figura 4.8.Transicin

4.2.4. Diagrama secuencial

Los diagramas de secuencia son un tipo de diagramas nombrados de interaccin, y
constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se
pueden enviar unos objetos a otros. Cubren la vista dinmica del sistema. Los diagramas
de secuencia enfatizan el ordenamiento temporal de los mensajes, mientras que los
diagramas de colaboracin muestran la organizacin estructural de los objetos que envan
y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de
colaboracin sin prdida de informacin, lo mismo ocurre en sentido opuesto.



Figura 4.9. Representacin de clases en diagramas de secuencia

Un diagrama de secuencia en el modelado UML muestra una interaccin ordenada segn
la secuencia de cada evento. Muestra los objetos participantes en la interaccin y los
mensajes que intercambian, ordenados segn su secuencia en el tiempo. El eje vertical
representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes
en la interaccin, sin un orden prefijado. Cada objeto o actor tiene una lnea vertical, y los
mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de
arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones
de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o
activaciones a las que se refieren.

4.2.5. Diagrama de clase

Los diagramas de clase son utilizados para mostrar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
contenido.
Un diagrama de clases est compuesto por los siguientes elementos: clase, atributos,
mtodos y visibilidad, y relaciones: herencia, composicin, agregacin, asociacin y uso.
Elementos
Clase
Es la unidad bsica que incluye toda la informacin de un Objeto, y un objeto es una
instancia de una clase. A travs de ella podemos modelar el entorno en estudio: una
Casa, un Auto, una Cuenta Corriente, etc.
En UML una clase es representada por un rectngulo que posee tres divisiones:



Figura 4.10.Representacin de una clase

Nivel Superior: Contiene el nombre de la Clase a utilizar.
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase
(pueden ser private, protected o public).
Nivel Inferior: Contiene los mtodos u operaciones, los cuales son la forma como
interacta el objeto con su entorno (dependiendo de la visibilidad: private, protected o
public).
Un ejemplo sobre el diagrama de clase:
Un Crdito que posee como caracterstica:
Solicitud

Puede realizar las operaciones de:

Investigacin de Crdito (investigacin)
Anlisis de crdito (anlisis)
Y Entrega de crdito (entrega)

El diseo asociado es:

Figura 4.11. Representacin de la clase cuenta


Atributos y Mtodos:

Atributos:

Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el
grado de comunicacin y visibilidad de ellos con el entorno, stos son:
public (+, ): Indica que el atributo ser visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
private (-, ): Indica que el atributo slo ser accesible desde dentro de la clase (slo
sus mtodos lo pueden accesar).
protected (#, ): Indica que el atributo no ser accesible desde fuera de la clase, pero
si podr ser accesado por mtodos de la clase adems de las subclases que se deriven
(ver herencia).

Mtodos:
Los mtodos u operaciones de una clase son la forma en cmo sta interacta con su
entorno, stos pueden tener las caractersticas:
public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.
private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase (slo
otros mtodos de la clase lo pueden accesar).
protected (#, ): Indica que el mtodo no ser accesible desde fuera de la clase, pero
s podr ser accesado por mtodos de la clase adems de mtodos de las subclases que
se deriven (ver herencia).

Actividad 2. Aplicacin de diagramas

Esta actividad tiene como finalidad aplicar cada uno de los conceptos bsicos de los
diagramas: casos de uso, actividades secuenciales y clase.

1. En un archivo de texto, realiza un listado en el que se mencionen cada uno de los tipos
de diagramas de casos de uso de actividades secuenciales y clase, incluye su definicin
y en qu utilizaras cada uno de ellos de acuerdo al concepto entendido.


2. Guarda la Actividad con el nombre DOO_U4_A2_XXYZ. Sustituye las XX por las dos
primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por la
inicial de tu apellido materno.

3. Enva el archivo a tu Facilitador(a) a travs de Tareas.

4.2.6. Diagrama de grfico de estado

El Diagrama de Estados especifica la secuencia de estados que pasa el caso de uso, o
puede ser un objeto a lo largo de su vida. Se indican qu eventos hacen que se pase de
un estado a otro y cules son las respuestas y acciones que da por resultado.

Un diagrama de estados es un grfico donde los nodos son estados y los arcos son
transiciones etiquetadas con los nombres de los eventos.

Un estado se representa como una caja redondeada con el nombre del estado en su
interior, una transicin se representa como una flecha desde el estado origen al estado
destino.

La caja de un estado puede tener uno o dos niveles: en el primer nivel aparece el nombre
del estado, el segundo nivel es opcional, y en l pueden aparecer acciones de entrada, de
salida y acciones internas.

Una accin de entrada aparece en la forma entrada/accin_asociada donde
accin_asociada es el nombre de la accin que se realiza al entrar en ese estado, cada
vez que se entra al estado por medio de una transicin, la accin de entrada se ejecuta.

Una accin de salida aparece en la forma salida/accin_asociada, cada vez que se sale
del estado por una transicin de salida la accin de salida se ejecuta. Una accin interna
es una accin que se ejecuta cuando se recibe un determinado evento en ese estado,

pero que no causa una transicin a otro estado. Se indica en la forma
nombre_de_evento/accin_asociada.

Figura 4.12. Grfico de estado de conexin a Internet

Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la
que hay un estado inicial de creacin y un estado final de destruccin (finalizacin del
caso de uso o destruccin del objeto). El estado inicial se muestra como un crculo slido
y el estado final como un crculo slido rodeado de otro crculo. En realidad, los estados
inicial y final no son estados, pues un objeto no puede estar en esos estados, pero nos
sirven para saber cules son las transiciones inicial(es) y final(es).

Actividad 3. Diseo de diagramas en UML

Esta actividad tiene como finalidad aplicar cada uno de los conceptos bsicos delos
diagramas casos de uso, actividades secuenciales, clase y grfico de estado.

1. En Word o Microsoft Visio disea un ejercicio para cada uno de los diagramas,
suponiendo que se quiere disear un sistema para el control de ventas de una farmacia
en donde el usuario sera el despachador de la misma.

2. Describe cada uno de los diagramas y su contenido o justificacin.

3. Guarda la Actividad con el nombre DOO_U4_A3_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por
la inicial de tu apellido materno.



Autoevaluacin

unidad del curso, es necesario que resuelvas la actividad integradora. Recuerda que es
muy importante leer cuidadosamente los planteamientos indicados y elegir la opcin
adecuada para cada uno.

Evidencia de aprendizaje. Diagramas UML

Como parte de la evaluacin de esta unidad, realiza la siguiente actividad cuyo propsito
es conceptualizar el proceso de diagramacin.

Instrucciones:

1. En un archivo de texto o Microsoft Visio disea un ejercicio para cada uno de los
diagramas que revisaste en esta unidad, sealando el o los usuarios.

2. Describe cada uno de los diagramas y su contenido o justificacin.

3. Consulta la Escala de evaluacin.

4. Guarda la evidencia con el nombre ADOO_U4_EA_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por
la inicial de tu apellido materno.

5. Enva el archivo a tu Facilitador(a) a travs de Evidencia de aprendizaje, para recibir
retroalimentacin.

Autorreflexiones

presente; a partir de ellas debes elaborar tu Autorreflexin en un archivo de texto llamado

Autorreflexiones.

Cierre de la unidad

Has concluido la unidad 4 del curso. A lo largo de sta se vieron conceptos de diseo
orientado a objetos con UML, cmo se representan los objetos y las clases, adems de
cmo se hacen los diagramas para los casos de uso, escenarios del caso de uso,
diagramas de actividades, diagramas secuenciales, de clase y el grfico de estado.

acaban de mencionar no te sean familiares, o no los recuerdes; de no ser ste tu caso, ya
habrs terminado tu curso de Anlisis y diseo Orientado a Objetos, FELICIDADES!

Para saber ms

Insertar o crear un dibujo de Visio en otro programa:

Cmo insertar en Word un diagrama en Visio: http://office.microsoft.com/es-
mx/visio-help/utilizar-visio-con-otros-programas-de-2007-microsoft-office-
system-HA010198865.aspx

Fuentes de consulta

Alarcn, Ral. (2005). Diseo orientado a objetos con UML. Grupo Eidos. Pgina
73.
Fowler, M. & Scott, K. (1999) UML GOTA A GOTA Mxico: Addison Wesley.
Gracia, J. (2003) UML: Casos de Uso. Use case, Desarrollo de Software Orientado
a Objetos. Recuperado de:
http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php

Kendall, J. & Kendall, J. (1990) Anlisis y Diseo de sistemas. Mxico: Prentice
Hall Iberoamericana.
Larman, C. (2004) Applying UML and Patterns an Introduction to object-Oriented
Analysis and Design. Mxico: Prentice Hall.
Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML
Mxico: Addison Wesley.

04 PD DS Doo PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

04 PD DS Doo PDF

Cargado por

Copyright:

Formatos disponibles

Anlisis y diseo orientado a objetos

También podría gustarte