04_PD_DS_DOO
-
Upload
robert-garrett -
Category
Documents
-
view
28 -
download
0
Transcript of 04_PD_DS_DOO
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 1
CARRERA: Ingeniería en Desarrollo de Software
Cuatrimestre 04
Programa de la asignatura:
Análisis y diseño orientado a objetos
Clave: 160920413 / 150920413
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 2
Índice
I. INFORMACIÓN GENERAL DE LA ASIGNATURA .............................................. 6 a. Ficha de identificación ............................................................................................................. 6
b. Descripción ............................................................................................................................... 6
c. Fundamentación teórica de la asignatura ............................................................................ 7
d. Propósito ................................................................................................................................... 8
e. Competencia(s) a desarrollar ................................................................................................. 9
f. Temario ....................................................................................................................................... 9
g. Metodología de trabajo ......................................................................................................... 11
h. Evaluación ............................................................................................................................... 11
i. Fuentes de consulta ................................................................................................................ 12
UNIDAD 1. INTRODUCCIÓN AL ANÁLISIS ORIENTADO A OBJETOS .............. 13 Presentación de la unidad ......................................................................................................... 13
Propósito ...................................................................................................................................... 13
Competencia específica ............................................................................................................ 13
Actividad 1. Presentación .......................................................................................................... 13
1.1. Generalidades ..................................................................................................................... 14
1.1.1. Definición .......................................................................................................................... 15
1.1.2. Características ................................................................................................................. 17
1.1.3. Ventajas ............................................................................................................................ 19
Actividad 2. Características y ventajas de la programación OO ......................................... 20
1.2. Identificación y conceptos básicos de modelos orientados a objetos ........................ 20
1.2.1. Abstracción ....................................................................................................................... 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
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 3
1.3.1. Definición .......................................................................................................................... 25
1.3.2. Espiral ............................................................................................................................... 26
1.3.3. Cascada ............................................................................................................................ 27
1.3.4. Incremental ....................................................................................................................... 28
Actividad 4. Conceptos básicos de los modelos Orientados a objetos ............................. 29
Autoevaluación ........................................................................................................................... 29
Evidencia de aprendizaje. Mapa mental de los modelos orientados a objetos ................ 29
Cierre de la unidad ..................................................................................................................... 30
Para saber más ........................................................................................................................... 30
Fuentes de consulta ................................................................................................................... 31
UNIDAD 2. REQUERIMIENTOS PARA EL ANÁLISIS DEL DISEÑO ORIENTADO A OBJETOS .......................................................................................................... 32
Propósito ...................................................................................................................................... 32
Competencia específica ............................................................................................................ 32
Presentación de la unidad ......................................................................................................... 32
2.1. Levantamiento de requerimientos .................................................................................... 34
Actividad 1. Análisis y diseño en un programa orientado a objetos ................................... 36
2.2. Documentación para levantamientos y especificaciones ............................................. 36
2.2.1. Documentación ................................................................................................................ 37
2.2.2. Especificaciones .............................................................................................................. 38
2.3. Estándares de Especificación ........................................................................................... 38
2.3.1. Fases de la estandarización .......................................................................................... 39
2.3.2. Análisis de restricciones ................................................................................................. 40
Actividad 2. Requerimientos, fases y restricciones para diseñar 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
Autoevaluación ........................................................................................................................... 46
Evidencia de aprendizaje. Requerimientos para diseñar un programa Orientado a
Objetos ......................................................................................................................................... 46
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 4
Cierre de la unidad ..................................................................................................................... 46
Fuentes de consulta ................................................................................................................... 47
UNIDAD 3. METODOLOGÍAS DE DISEÑO PARA LA GENERACIÓN DE SISTEMAS ORIENTADOS A OBJETOS .............................................................. 48
Presentación de la unidad ......................................................................................................... 48
Propósito ...................................................................................................................................... 50
Competencia específica ............................................................................................................ 51
3.1. Booch .................................................................................................................................... 51
3.1.1. Introducción ...................................................................................................................... 51
3.1.2. Modelos ............................................................................................................................. 52
3.2. OOSE ................................................................................................................................... 57
3.2.1. Introducción ...................................................................................................................... 58
3.2.2. Modelos ............................................................................................................................. 60
3.3. OMT ...................................................................................................................................... 63
3.3.1. Introducción ...................................................................................................................... 64
3.3.2. Modelos ............................................................................................................................. 65
Actividad 1. Metodología para la generación de sistemas OO ........................................... 67
3.4. UML....................................................................................................................................... 67
3.4.1. Introducción ...................................................................................................................... 68
3.4.2. OCL (Lenguaje de Especificaciones de Objetos)....................................................... 70
Actividad 2. Cuadro comparativo de las diferentes metodologías ...................................... 71
Autoevaluación ........................................................................................................................... 72
Evidencia de aprendizaje. Cuadro comparativo de los métodos de modelado ................ 72
Cierre de la unidad ..................................................................................................................... 73
Para saber más ........................................................................................................................... 73
Fuentes de consulta ................................................................................................................... 74
UNIDAD 4. DISEÑO ORIENTADO A OBJETOS CON UML (LENGUAJE UNIFICADO DE MODELADO) .............................................................................. 75
Presentación de la unidad ......................................................................................................... 75
Propósito ...................................................................................................................................... 75
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 5
Competencia específica ............................................................................................................ 75
4.1. Representación de objetos y clases con UML ............................................................... 76
4.1.1. Representación de clases con UML ............................................................................. 76
4.1.2. Representación de objetos con UML ........................................................................... 77
Actividad 1. Representación de clases y objetos con UML ................................................. 78
4.2. Diagramas y documentación para el diseño 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. Aplicación de diagramas ...................................................................................... 91
4.2.6. Diagrama de gráfico de estado ..................................................................................... 92
Actividad 3. Diseño de diagramas en UML ............................................................................ 93
Autoevaluación ........................................................................................................................... 94
Evidencia de aprendizaje. Diagramas UML ........................................................................... 94
Cierre de la unidad ..................................................................................................................... 95
Para saber más ........................................................................................................................... 95
Fuentes de consulta ................................................................................................................... 95
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 6
I. Información general de la asignatura
a. Ficha de identificación
Nombre de la Ingeniería: Desarrollo de software
Nombre del curso o asignatura: Análisis y diseño orientado a objetos
Clave de asignatura: 160920413 / 150920413
Seriación: No aplica
Cuatrimestre: Cuarto
Horas contempladas: 72 horas
b. Descripción
El hecho de pensar cómo o por dónde empezar a analizar los datos para diseñar un
programa de computadora es una labor complicada, más aun si el programa que se
quiere realizar está pensado en la metodología con orientación a objetos, la cual data de
los años cincuenta y no se usaba hasta hace poco porque la tecnología no estaba acorde
con su implementación. Hoy en día, la tecnología orientada a objetos se aplica desde que
se hace el análisis de un problema y sobre todo en el diseño de un programa que luego
será pasado a código en un lenguaje específico para dar solución a la necesidad de
automatizar la información de la empresa.
Los conceptos de análisis y diseño orientado a objetos surgen a partir de los lenguajes
modernos de programación. Aprovechando los beneficios de trabajar bajo este enfoque,
si se hace un buen análisis y diseño previo, el proceso de programación se vuelve fácil de
desarrollar y se obtienen mejores resultados.
En el análisis orientado a objetos se desarrollan una serie de modelos que nos orientan
sobre el software o lenguaje de programación a trabajar y así satisfacer un conjunto de
requisitos definidos por el cliente. El modelo del análisis orientado a objetos ilustra la
información, el funcionamiento y el comportamiento que llevará el flujo de la información
desde que se introduce, hasta lo que la computadora va a arrojar como resultado,
transformando el análisis de los datos en un modelo de diseño que sirve como
anteproyecto para la construcción de software, convirtiéndolo así incluso en un software
de fácil mantenimiento.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 7
c. Fundamentación teórica de la asignatura
La asignatura de Análisis y diseño orientado a objetos tiene como función principal que se
aprenda a responder a las necesidades de flexibilidad en los sistemas de información,
mediante el manejo de los conceptos básicos de los modelos orientados a objetos tales
como herencia, polimorfismo, abstracción, etc. Dichos modelos han sido desarrollados
para que los sistemas sean más flexibles y el mantenimiento se vuelva sencillo. Mientras
que el desarrollo orientado a objeto involucra una fase de análisis y diseño más amplia,
esta inversión se traduce en menores costos de mantenimiento.
Existen varias metodologías 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 técnicas para el análisis y diseño Orientadas a Objetos todavía están
en desarrollo, esto debido a que la programación misma aún se encuentra en esta etapa.
Han surgido tantas metodologías que tratan este modelo de programación, siendo una de
las más usadas UML (Lenguaje Unificado de Modelado) por ser más eficiente en este
enfoque. Por lo anterior, en esta asignatura es necesario abordar una parte introductoria
sobre esta metodología (unidad 1), donde se abarcan conceptos generales del análisis,
los modelos orientados a objetos y el ciclo de vida del software. Estos conceptos se
utilizarán para poder llegar a la unidad 2, en la que se elaboran los papeles de trabajo
para este tipo de análisis con orientación a objetos. Así pues las unidades 1 y 2 están
enfocadas al análisis, mientras que en las unidades 3 y 4 se abarca lo concerniente al
diseño orientado a objetos.
Desde el inicio de la primera unidad, el estudiante interactúa con las herramientas del aula
virtual, como foros y bases de datos. Posteriormente, se llevan a cabo trabajos, así como
también se presentan actividades de investigación que complementan los contenidos, lo
que permite ejercitar y presentar sus evidencias de aprendizaje de los temas vistos en
cada unidad.
El enfoque teórico metodológico en el cual se sustenta la asignatura es un enfoque mixto,
donde se considerarán los siguientes aspectos:
Criterio cuantitativo: número de aportaciones: mínimo 2/tema a discutir.
Criterio cualitativo a través de escalas:
o Excelente: 100
o Bien: 80
o Regular: 60
o Insuficiente: 50
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 8
d. Propósito
El propósito general de la asignatura es realizar los diagramas que se requieren usando
como base el análisis de un sistema con orientación a objetos mediante las herramientas
de un lenguaje gráfico -como UML (Lenguaje Unificado de Modelado)- para visualizar,
especificar, construir y documentar un sistema.
La asignatura de Análisis y diseño orientado a objetos forma parte del cuarto cuatrimestre
de la Ingeniería en Desarrollo de software. La materia sirve de apoyo para la asignatura
de Programación orientada a objetos, además servirá como base para las asignaturas de
Programación orientada a objetos II y III de posteriores cuatrimestres y tiene como
asignatura precedente a Fundamentos de programación.
El curso se encuentra conformado por cuatro unidades:
1. Introducción al análisis orientado a objetos
2. Requerimientos para el análisis del diseño orientado a objetos
3. Metodologías de diseño para la generación de sistemas orientados a objetos
4. Diseño orientado a objetos con UML (Lenguaje Unificado de Modelado)
En la unidad 1 se presenta una introducción al análisis orientado a objetos, desde su
definición y características, hasta las ventajas de hacer un buen análisis para lograr un
diseño orientado a objetos, así como los conceptos básicos 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 análisis del diseño orientado a objetos, donde se revisa el levantamiento
de requerimientos, los estándares de especificación y los modelos del desarrollo de
software. En la unidad 3 se exponen las diferentes metodologías para el diseño de
sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /
Ingeniería de Software Orientado a Objetos), OMT (Object Modeling Technique / Técnica
de Modelado de Objetos) y UML (Unified Modeling Language / Lenguaje Unificado de
Modelado). Finalmente, en la unidad 4, se trabaja el diseño orientado a objetos con
diagramas UML, con el fin de tener un diagrama de fácil entendimiento que podrá ser
convertido en un diseño con orientación a objetos, logrando que sea fácil de codificar en
cualquier lenguaje con programación orientada a objetos.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 9
e. Competencia(s) a desarrollar
Competencia general:
Diagramar la estructura de un sistema orientado a objetos para su diseño con base en el
análisis del sistema mediante el uso de UML (Lenguaje Unificado de Modelado).
Competencias específicas:
Identificar las etapas de un sistema orientado a objetos para decidir su ciclo de
vida, utilizando los conceptos de orientación a objetos.
Distinguir los requerimientos del sistema orientado a objetos en su etapa de
análisis para definir su diseño mediante técnicas y estándares de especificación.
Comparar las metodologías de diseño para la generación de sistemas orientados a
objetos mediante los diagramas con los métodos de modelado Booch, OOSE,
OMTy UML.
Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos
mediante el método de modelado UML.
f. Temario
Unidad 1. Introducción al análisis orientado a objetos
1.1. Generalidades
1.1.1. Definición
1.1.2. Características
1.1.3. Ventajas
1.2. Identificación y conceptos básicos de modelos orientados a objetos
1.2.1. Abstracción
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. Definición
1.3.2. Espiral
1.3.3. Cascada
1.3.4. Incremental
Unidad 2. Requerimientos para el análisis del diseño orientado a objetos
2.1 . Levantamiento de requerimientos
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 10
2.1.1. Introducción a los requerimientos
2.1.2. Actividades para el levantamiento de requerimientos
2.2 . Documentación para levantamientos y especificaciones
2.2.1 Documentación
2.2.2 Especificaciones
2.3 . Estándares de especificación
2.3.1 Fases de la estandarización
2.3.2 Análisis de restricciones
2.4 . Modelos del desarrollo de software
2.4.1. Ágiles
2.4.2. Predictivos
Unidad 3. Metodologías de diseño para la generación de sistemas orientados a objetos
3.1. Booch
3.1.1. Introducción
3.1.2. Modelos
3.2. OOSE
3.2.1. Introducción
3.2.2. Modelos
3.3. OMT
3.3.1. Introducción
3.3.2. Modelos
3.4. UML
3.4.1. Introducción
3.4.2. OCL (Lenguaje de Especificación de Objetos)
Unidad 4. Diseño orientado a objetos con UML (Lenguaje Unificado de Modelado)
4.1. Representación de objetos y clases con UML
4.1.1. Representación de clases con UML
4.1.2. Representación de objetos con UML
4.2. Diagramas y documentación para el diseño 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 gráfico de estado
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 11
g. Metodología de trabajo
El aprendizaje basado en la resolución de problemas es una metodología en la que se
presentan situaciones diversas para que se lleve a cabo la aplicación de fórmulas,
algoritmos y procedimientos, así mismo rutinas que permitan ejercitar y poner en práctica
los conocimientos y procedimientos para promover el reforzamiento de lo aprendido o la
resolución de dudas, así como el aprendizaje significativo, al comprobar los elementos
teóricos.
Al aplicar este tipo de metodología en la asignatura, también se toman en cuenta:
El uso de las siguientes herramientas tecnológicas: a) un foro general al inicio de la
asignatura cuyo propósito es favorecer la comunicación 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 realización 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 documentación a requerimientos, también elaborar
secuencias de tiempo investigaciones y diseñar diagramas como parte final para la
aplicación del conocimiento adquirido.
La construcción del portafolio de evidencias (e-portafolio), el cual consta de la
elaboración de mapas mentales para evidenciar el conocimiento adquirido,
levantamientos de requerimientos, cuadros sinópticos y diseño de diagramas con
problemas relativos a los temas abordados en cada una de las unidades que
integran la asignatura, que reflejen la utilización de los conocimientos adquiridos a lo
largo de ésta.
La realización de actividades de autoevaluación que den cuenta del grado de
aprendizaje adquirido y refuercen los conocimientos.
h. Evaluación
En el marco del Programa ESAD, la evaluación se conceptualiza como un proceso
participativo, sistemático 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 participación responsable y activa
del estudiante, así como una comunicación estrecha con su Facilitador(a) para que pueda
evaluar objetivamente su desempeño, para lo cual es necesaria la recolección de
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 12
evidencias que permitan apreciar el proceso de aprendizaje de contenidos: declarativos,
procedimentales y actitudinales.
En este contexto la evaluación es parte del proceso de aprendizaje, en el que la
retroalimentación 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 participación en foros y demás actividades
programadas en cada una de las unidades, y conforme a las indicaciones dadas. La
calificación se asignará de acuerdo con la rúbrica establecida para cada actividad, por lo
que es importante que el estudiante la revise antes de realizar las actividades.
A continuación presentamos el esquema general de evaluación.
ESQUEMA DE EVALUACIÓN
Evaluación
continua
Interacciones individuales y
colaborativas 10%
Tareas 30%
E-portafolio.
50%
Evidencias 40%
Autorreflexiones 10%
Examen 10%
CALIFICACIÓN
FINAL 100%
Cabe señalar que para aprobar la asignatura, se debe de obtener la calificación mínima
indicada por ESAD.
i. Fuentes de consulta
Bibliografía básica
Booch-Grady (1996). Análisis y Diseño Orientado a objetos con aplicaciones.
México: Pearson Educación.
Kendall, E. (2005). Análisis y Diseño de sistemas. México: Pearson Educación.
Seen, J. (1990). Análisis y Diseño de sistemas de Información. México: Mc Graw
Hill.
Bibliografía complementaria
Sommerville, I. (2005). Ingeniería del Software. México: Pearson Educación.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 13
Unidad 1. Introducción al análisis orientado a objetos
Presentación de la unidad
Bienvenido(a) a la asignatura Análisis y diseño orientado a objetos. En esta primera
unidad se expondrán los principios fundamentales de un buen análisis para hacer un
correcto diseño y así poder programar con orientación a objetos, lo que permitirá dar
cumplimiento al propósito de la unidad.
En la primera parte de esta unidad te enfrentarás en la sección de análisis y diseño, con
algunos conceptos básicos como la definición, las características y las ventajas de hacer
un análisis previo de la información y deberás conocer, en la segunda parte de esta
unidad, los conceptos de orientación a objetos para que cuando hagas tu diseño sepas
darle ese enfoque, también distinguirás las características de este tipo de programación.
Finalmente, conocerás el ciclo de vida del software y algunos tipos de ciclos. Toda esta
información es el principio básico de un buen análisis de diseño orientado a objetos.
Propósito
Conocer los atributos de los modelos orientados a objetos para poder establecer las
necesidades del diseño de un sistema con estas características, así como ubicar las
etapas de vida del software.
Competencia específica
Identificar las etapas de un sistema orientado a objetos para decidir su ciclo de vida,
utilizando los conceptos de orientación a objetos.
Actividad 1. Presentación
Antes de entrar de lleno en el estudio de la asignatura, te presentamos un foro de
discusión general, el cual fue creado con la finalidad de que te presentes con tus
compañeros y comentes cualquier asunto relacionado con la asignatura; en él, conocerás
a tus compañeros de grupo y entre todos podrán apoyarse para resolver dudas,
inquietudes, externar comentarios, etcétera.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 14
Para comenzar tu participación, ingresa al foro Presentación.
1.1. Generalidades
El objetivo principal del análisis orientado a objetos (AOO), es desarrollar un software
capaz de cubrir con las necesidades esenciales del usuario final, y su diseño se enfoca
en los objetos.
El análisis orientado a objetos y su diseño se basa en definir una serie de actividades
relevantes al problema que se va a resolver, en donde son comúnmente utilizadas las
operaciones y atributos asociados. Para cumplir con esto se deben tener en cuenta las
siguientes tareas:
1.- Debe de existir una comunicación sobre los requisitos básicos del usuario ya que
será el usuario final del software.
2.- Se deben definir los métodos a utilizar para el análisis.
3.- Se debe definir la jerarquía de los métodos utilizados para el análisis.
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 más fácil de mantener debido a que su estructura es
inherentemente poco acoplada. Además los sistemas orientados a objetos son más
fáciles de adaptar y escalables.
El enfoque realizado sobre el desarrollo orientado a objetos no debe implicar hacer las
tareas diferentes del enfoque clásico de desarrollo de software puesto que se
desarrollan actividades similares en un proceso evolutivo.
El modelo orientado a objetos tiene como característica el hecho de que un elemento
del mundo real se puede representar a través de sus características y de sus
comportamientos.
Los conceptos como clase, objeto, instancia, atributos y métodos, se hacen cotidianos
en el AOO, ya que son parte de su vocabulario.
Los conceptos fundamentales que llevan a un diseño de alta calidad son igualmente
aplicables a sistemas desarrollados usando métodos orientados a objetos. Por esa
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 15
razón, un AOO debe exhibir abstracciones de datos y procedimientos que conducen a
una modularidad eficaz.
La gestión de un proyecto de software orientado a objetos por lo general tiene
actividades como:
1.- Establecer un proceso común para el proyecto.
2.- Usar métricas para desarrollar estimaciones de tiempo y esfuerzo.
3.- Especificar productos de trabajo e hitos que permitirán medir el progreso.
4.- Tener puntos de comprobación para la gestión 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 básicos comúnmente usados:
1.- Modelado de la información.
2.- Descripción de funciones.
3.- Representación del comportamiento del modelo.
4.- Desarrollo de modelos de datos, funcional y de comportamiento.
El análisis y desarrollo orientado a objetos puede ser interpretado como el conjunto de
disciplinas que desarrollan y modelan un software que facilita la construcción de
sistemas de información complejos a partir de la formación de sus componentes.
Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir
sistemas de software complejos a partir de unidades de software, el enfoque del AOO
debe ser capaz de manipular sistemas grandes y pequeños que sean flexibles con
facilidad de mantenimiento y capaces de evolucionar con respecto a las necesidades y
requerimientos del usuario final.
1.1.1. Definición
Para comenzar a entender en qué consiste el análisis y diseño de software orientado a
objetos, empezaremos por definir el término orientado a objetos, pero vayamos por
partes, como se muestra a continuación:
Objeto: Instancia de una clase específica. Los objetos heredan los atributos y
operaciones de una clase.
Clase: Representa a una entidad que tiene un estado interno y un comportamiento
característico.
Atributos: Son los datos a los que se refiere el estado del objeto (Booch-Grady, 1996).
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 16
Los objetos tienen un estado interno y un comportamiento, el estado de un
determinado objeto es un conjunto de parámetros con valores que lo caracterizan.
Estos parámetros 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 método. Los
métodos podrían ser:
Dibujar un triángulo
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 métodos, sobre los cuales ejecuta las
operaciones que manifiesta su comportamiento.
El análisis orientado a objetos (AOO) construye un modelo orientado a objetos y a las
clases que se basan en la comprensión de los conceptos orientado a objetos (OO).
El enfoque orientado a objetos permite que los objetos estén auto-contenidos. Los
objetos existen por sí mismos, con una funcionalidad para invocar comportamientos de
otros objetos. Por definición son modulares, es decir, pequeñas unidades lógicas de
códigos independientes entre sí que se comunican entre ellas mediante mensajes en su
construcción. 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 mayoría de los programadores desarrolla sobre un lenguaje y solo
utiliza su propio estilo de programación. Desarrollan sobre un paradigma forzado por el
lenguaje que utilizan, tienden a no enfrentarse a métodos alternativos de resolución de
un problema y como resultado se presentan con la dificultad de ver las ventajas de elegir
un estilo más apropiado al problema a manejar. Autores como Bobrow y Stefik (1986,
citados en Booch-Grady, 1996) sugieren que existen cuatro clases de estilo de
programación:
Orientada a procedimientos (Algoritmos).
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 17
Orientada a objetos (Clases y objetos).
Orientada a la lógica (Expresado en cálculo de predicados).
Orientada a reglas (Reglas if-Then).
Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software
que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque
representa un dominio en términos de conceptos compuestos por verbos y sustantivos,
clasificados de acuerdo a su dependencia funcional.
En este método de análisis y diseño se crea un conjunto de modelos utilizando una
notación acordada, como por ejemplo, el lenguaje unificado de modelado (UML). ADOO
aplica técnicas de modelado de objetos para analizar los requerimientos en un contexto
(un sistema de negocio, un conjunto de módulos de software) y para diseñar una solución
para mejorar los procesos involucrados. Este método no está restringido al diseño de
programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las
metodologías de análisis y diseño más modernas son casos de uso guiados a través de
requerimientos, diseño, implementación, pruebas, y despliegue.
El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado
en análisis y diseño orientado a objetos.
Las estrategias que se utilizan para hacer un correcto desarrollo orientado a objetos son:
análisis, diseño y programación. En el análisis se consideran las actividades que hay que
hacer para desarrollar un programa OO y se identifican los objetos, transformándolos en
entidades y operaciones para asociarlos con el problema a resolver. En el diseño, los
objetos se relacionan con la solución del problema. Finalmente, en la programación se
hace la codificación del problema en algún lenguaje con orientación a objetos.
1.1.2. Características
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 están definidos en su clase común.
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 característica esencial de él. Es
complejo porque hereda la complejidad del problema, la dificultad de gestionar el proceso
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 18
de desarrollo, la flexibilidad que se puede alcanzar a través 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, además, son cambiados con frecuencia durante el desarrollo,
incluso porque la mera existencia de un proyecto de solución altera al sistema real.
3. Un sistema grande, debido a la inversión financiera que implica, no puede
desecharse y reemplazarse por uno nuevo cada vez que los requisitos cambian, debe
evolucionar, considerando:
Evolución del software: responder al cambio de requerimientos.
Mantenimiento del software: corregir errores.
Conservación del software: emplear recursos para mantener en operación un elemento
de software anticuado y decadente.
4. La principal tarea del grupo de desarrollo es dar una ilusión de simplicidad para los
usuarios de esta complejidad arbitraria del problema, se hace lo posible por escribir
menos código pero a veces es imposible y más en un sistema tan grande, por lo que
se debe recurrir a la aplicación de varias técnicas de re-utilización de código
existente.
5. Debe también enfrentarse la existencia de miles de módulos 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 pequeña modificación en la entrada provoca una
pequeña modificación en la salida. Mientras que en otros, y sobre todo de gran
tamaño, se percibe una explosión combinatoria que hace que la salida se modifique
enormemente.
8. Se intenta diseñar los sistemas con una separación de intereses, de forma que el
comportamiento de una parte del sistema tenga el mínimo 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 corrección, ya que no puede llevarse a cabo una
prueba a fondo exhaustiva por no tener las herramientas matemáticas ni intelectuales
para un sistema no continuo.
10. Las consecuencias de la complejidad ilimitada. Mientras más complejo es el
sistema, más 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
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 19
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 programación 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
diseños completos.
Tercero, produce sistemas que están construidos en formas intermedias estables
y por ello son más resistentes al cambio en especificaciones y tecnología.
Se considera que el principal beneficio del AOO, es que da un esquema para formalizar
el modelo real.
El análisis orientado a objetos (AOO) es un método de análisis que examina los
requerimientos desde la perspectiva de las clases y objetos encontrados en el
vocabulario del dominio del problema. El diseño orientado a objetos es un método de
diseño que abarca el proceso de descomposición orientado a objetos y una notación
para representar ambos modelos (lógico y físico), como los modelos estáticos y
dinámicos del sistema bajo diseño.
Dentro de las metodologías del análisis y diseño orientado a objetos, hay una variedad
de métodos en la actualidad. Muchos de los métodos pueden ser clasificados como
orientados a objetos porque soportan de manera central los conceptos de la orientación
a objetos. Algunas de las metodologías más conocidas y estudiadas hasta antes de UML
(Jacobson 1996, citado en Booch-Grady, 1996) son:
METODOLOGÍA AUTOR
Diseño orientado a
objetos (DOO) Grady Booch
Técnica de modelado de
objetos (TMO) Rumbaugh
Análisis orientado a
objetos (AOO) Coad/Yourdon
Jerarquía de diseño
orientada a objetos
(JDOO)
ESA
Diseño estructurado Wasserman
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 20
orientado a objetos
(DEOO)
Análisis de sistemas
orientado a objetos
(ASOO)
Shaler y Mellor, entre
otros
Actualmente las metodologías más importantes de análisis y diseño 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 día, el ADOO puede que sea el único método que logre emplearse para
atacar la complejidad innata de muchos sistemas grandes. Sin embargo, puede no ser
aconsejable en dominios, no por razones técnicas sino por cuestiones como falta de
personal con entrenamiento adecuado o buenos entornos de desarrollo.
Lo interesante de la Programación 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. Características y ventajas de la programación OO
Con el fin de reflexionar sobre la importancia de hacer un adecuado análisis y diseño
previo para realizar un buen programa, tomando en cuenta los temas abordados, realiza
lo que se te pide a continuación:
1. Retoma los conceptos desarrollados hasta ahora. 2. Identifica las diferencias entre análisis, diseño y programación orientada a objetos. 3. Ingresa al foro y realiza lo que en él se te pide.
1.2. Identificación y conceptos básicos de modelos orientados a
objetos
El análisis orientado a objetos es una forma de hacer frente a la comprensión y solución
de problemas, usando modelos a partir de conceptos. La pieza fundamental es el objeto,
el cual se combina en una sola entidad.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 21
Para dar énfasis sobre los conceptos en el análisis orientado a objetos, a continuación se
detallan los más básicos o utilizados con mayor frecuencia.
Objeto: Es una entidad bien definida, real o abstracta, que tiene sentido sobre el contexto
de alguna aplicación 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 automóvil, un profesor.
Conceptuales: Ejemplo de objetos conceptuales, un programa de computadora,
una variable de programación, un pensamiento.
Atributo: Es un valor atribuido a un objeto, por ejemplo un alumno es un objeto y sus
atributos podrían ser su número de control, su nombre y su calificación. Se entiende que
se pueden llegar a tener más atributos, pero si el contexto de la aplicación es solo obtener
un resultado específico, los atributos serán los únicos que son relevantes para esa
aplicación.
Comportamiento: Es el conjunto de cada acción o transformación que el objeto ejecuta,
también podría ser llamado operación y método. Por ejemplo, para el objeto alumno se
requiere de algunas acciones y transformaciones: asignar calificación, leer nombre y leer
número de control; estas acciones representan el comportamiento del objeto alumno. En
el caso de asignar calificación, leer nombre y leer número de control, se refieren a
transformaciones, ya que modificarán el valor de la calificación final.
Identificación: Cada objeto posee una identificación mediante la cual se puede hacer
alusión a él de modo exclusivo.
Clase: describe propiedades importantes para una aplicación y que ignora el resto. La
selección de clases es arbitraria y depende de la aplicación.
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 aún si el valor de todos sus atributos es idéntico.
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 característica de identidad de los
objetos.
Clasificación. Se refiere a que los objetos con los mismos atributos y comportamiento –
métodos-, 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
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 22
de objetos individuales. Por ejemplo a todos los alumnos que aparecerán 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. Abstracción
En la abstracción la mente humana modela la realidad en forma de objetos. Para ello
busca semejanzas entre la realidad y la posible implementación 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 cómo, cuándo, donde o por qué las cosas, solamente necesitamos saber que
cuando queremos caminar lo haremos y punto.
Es la caracterización de un objeto de acuerdo a las propiedades que nos interesen en un
instante de tiempo. Las características escogidas son relativas a la perspectiva del
observador.
Figura 1.1. Abstracción.
1.2.2. Encapsulamiento
Cuando un objeto es encapsulado tenemos la libertad de saber qué información se hace
pública o no, para ello podemos hacer privados e inaccesibles los datos de este objeto a
través otro previamente publicado.
Con esto logramos que los datos solo sean utilizados por su interfaz dejando de lado
cómo está implementada, haciendo así, más fácil la utilización del mismo.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 23
Así pues, la manera de ocultar los detalles de la representación interna de un objeto es
presentando solo la interface para el usuario.
Figura 1.2. Encapsulamiento.
1.2.3. Modularidad
A través de la modularidad, se propone al programador dividir su aplicación en varios
módulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos
con un sentido propio.
Esta fragmentación 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,
además de facilitar la comprensión del programa.
1.2.4. Herencia
La herencia se base en la capacidad para reflejar la abstracción que realiza
automáticamente y se refiere a compartir atributos y métodos entre objetos que se
relacionan de manera jerárquica durante un proceso de análisis de información.
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 relación entre clases en
la orientación a objetos.
Del mismo modo, las distintas clases de un programa se organizan mediante la jerarquía.
La representación de dicha organización da lugar a los denominados árboles de herencia:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 24
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 fácilmente identificable, puede ser muy
útil para el desarrollo de programas informáticos. Del mismo modo,
Relaciona las clases de manera jerárquica; 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 acción determinada o que modifique su estado. El paso de mensajes se suele
implementar como llamadas a los métodos de otros objetos.
Desde el punto de vista de la programación estructurada, esto correspondería con la
llamada a funciones” (García, s/f: 1)
Ahora bien, el polimorfismo es una característica de la orientación a objetos, que significa
que un mismo método puede tener diferente manera de realizarse, en las diferentes
clases que haya bajo estudio. Cada objeto perteneciente a una clase y “sabe cómo”
ejecutar sus propios métodos. Cuando se programa orientado a objetos, el lenguaje de
programación automáticamente selecciona el método correcto para efectuar una cierta
acción o transformación sobre el objeto al que se aplica. Por ejemplo, si tenemos los
objetos bicicleta, carro, barco y les aplicamos la operación Mover, la acción se ejecuta de
manera diferente para cada objeto. Otro ejemplo típico es el de los objetos de la clase
Figura, digamos círculo, rectángulo, triángulo, apliquémosles la acción de Dibujar, cada
uno de ellos tendrá su propio método Dibujar definido, ya que la acción debe
implementarse de manera diferente para cada objeto.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 25
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 zapatería) y describe qué haría en cada una
de las etapas en los ciclos cascada y espiral incremental.
Ejemplo:
Modelo de ciclo de
vida de zapatería Etapa Descripción
Espiral Planificación En esta etapa en
la zapatería se va
a…
2. Guarda tu actividad con la nomenclatura DOO_U1_A3_XXYZ.
3. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
1.3. Ciclo de vida del software y tipos de ciclos
La metodología para el desarrollo de software tiene pasos establecidos en la realización y
administración de un proyecto para llevarlo a cabo con éxito. Para facilitar esto, se debe
dividir un gran proyecto en módulos más pequeños 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. Definición
Llevar a cabo la metodología para el desarrollo del software requiere seguir puntualmente
una serie de pasos o procesos para analizar, diseñar 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:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 26
Planificación: planteamiento detallado que los pasos a seguir durante el
desarrollo del proyecto, considerando aspectos de tiempo y dinero.
Implementación: decidir las actividades que componen la realización del
producto.
Producción: 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 variación del modelo prototípico que fue
diseñado por Boehm en el año 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 perfección de todas las funcionalidades o módulos.
En este modelo hay cuatro actividades principales para las etapas:
Planificación: Relevamiento de requerimientos iniciales o luego de una iteración.
Análisis del riesgo: De acuerdo con el relevamiento de requerimientos decidimos
si continuamos con el desarrollo.
Implementación: Desarrollamos un prototipo basado en los requerimientos.
Evaluación: El cliente evalúa el prototipo, si da su conformidad termina el
proyecto. En caso contrario incluimos los nuevos requerimientos solicitados por el
cliente en la siguiente iteración.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 27
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 ingeniería de sistemas más generales (Royce, 1970, citado en Sommerville,
I. 2005).
A continuación se ve cómo de un diseño 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. Análisis y definición de requerimientos. Los servicios, restricciones y metas del
sistema se definen a partir de las consultas con los usuarios.
2. Diseño del sistema y del software. El proceso de diseño del sistema divide los
requerimientos en sistemas hardware o software.
3. Implementación y prueba de unidades. Durante esta etapa, el diseño del software se
lleva a cabo como un conjunto o unidades de programas.
4. Integración 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.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 28
5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), esta
es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento
práctico. 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 módulos que cumplen las diferentes funciones del sistema, lo
que permite ir aumentando gradualmente las capacidades del software. Desarrollar un
módulo o módulos 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 pequeño siempre es menos riesgoso que construir un
sistema grande.
Como desarrollamos independientemente las funcionalidades, es más fácil relevar
los requerimientos del usuario.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 29
Si se detecta un error grave solo se desecha la última iteración.
No es necesario disponer de los requerimientos de todas las funcionalidades en el
comienzo del proyecto y además facilita la labor del desarrollo con la conocida
filosofía de divide y vencerás
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 básicos de los modelos Orientados a objetos
Con el fin de distinguir cada uno de los conceptos básicos de la programación orientada a
objetos, en esta actividad debes proponer ejemplos que hagan referencia a cada uno de
ellos: abstracción, encapsulamiento, polimorfismo, modularidad, herencia, jerarquía y
paso de mensajes. Con base en lo anterior, realiza lo que a continuación se te pide:
1. En un archivo de texto, anota el nombre de cada concepto básico de los sistemas
orientados a objetos.
2. De acuerdo con la definición 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.
4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
Autoevaluación
Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
primera unidad del curso, es necesario que resuelvas la autoevaluación de la unidad.
Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y
elegir la opción adecuada para cada uno.
Evidencia de aprendizaje. Mapa mental de los modelos orientados a
objetos
Como parte de la evaluación de esta unidad, llevarás a cabo esta actividad cuyo propósito
es organizar los conceptos abordados a lo largo de la unidad con la finalidad de tener
presente las definiciones revisadas. Realiza lo siguiente:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 30
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, líneas que representan uniones entre ellos e imágenes que pueden
substituir textos.
2. Consulta la Escala de evaluación.
3. Guarda tu evidencia con la nomenclatura DOO_U1_EA_XXYY.
4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación. Recuerda que
puedes volver a enviar tu archivo tomando en cuenta las observaciones de tu
Facilitador(a).
Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a)
presente, a partir de ellas, debes elaborar tu Autorreflexión en un archivo de texto llamado
DOO_U1_ATR_XXYZ. Posteriormente envía 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 análisis orientado a objetos, su definición, características y ventajas.
Posteriormente identificaste los conceptos básicos de los modelos orientados a objetos,
tales como abstracción, encapsulamiento, modularidad, herencia y polimorfismo, cuyo
propósito 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 diseñar 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
estás preparado(a) para seguir con la unidad 2, en donde abordarás los requerimientos
para el análisis del diseño orientado a objetos, realizarás levantamientos de
requerimientos y la documentación necesaria, teniendo en cuenta los estándares que
deben cumplir y los tipos de modelos para el desarrollo de software.
Para saber más
Si deseas saber más acerca de la programación orientada a objetos, visita las siguientes
direcciones electrónicas:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 31
I.1. INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS:
http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/
Programación orientada a objetos: http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm
Fuentes de consulta
Bibliografía básica
Booch-Grady (1996). Análisis y Diseño Orientado a Objetos con Aplicaciones.
México: Pearson Educación.
Kendall, E. (2005). Análisis y Diseño de Sistemas. México: Pearson Educación.
Seen, J. (1990). Análisis y Diseño de Sistemas de Información. México: Mc Graw
Hill.
Bibliografía complementaria
Ciberaula (2010). Programación 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. México: Prentice-Hall.
Fernández, S. (1995). Fundamentos del diseño y la programación orientada a
objetos. México: McGraw Hill.
García, F. (s/f). I.1. Introducción a la programación 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). Ingeniería del Software. México: Pearson Educación.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 32
Unidad 2. Requerimientos para el análisis del diseño Orientado a
Objetos
Propósito
La especificación de requisitos es la primera fase de todo ciclo de vida o metodología de
desarrollo de un proyecto informático. Dos son sus objetivos principales:
Identificar las necesidades del cliente, es decir, conocer y definir el problema.
Realizar un estudio de viabilidad económico, técnico y legal, a partir del cual se
pueda decidir sobre la continuación del proyecto, teniendo en cuenta las
alternativas de construcción del mismo que se nos planteen.
Estos dos objetivos principales se concretan en una serie de acciones a realizar, unas
técnicas a aplicar y unos productos a obtener. Resulta obvio (en cualquier contexto, no
solo en el terreno informático) 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 definición, desde el punto de vista puramente
técnico, del proyecto. Un aspecto importante a tener en cuenta es la identificación de los
tipos de usuarios potenciales que tendrá el sistema.
Competencia específica
Distinguir los requerimientos del sistema orientado a objetos en su etapa de análisis para
definir su diseño mediante técnicas y estándares de especificación.
Presentación de la unidad
El trabajo de ir detallando la definición de un problema en forma de requisitos se realiza
de manera repetitiva, progresiva, incremental. Por un lado, supone la planificación,
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 33
realización y evaluación de las entrevistas con los clientes y usuarios finales del sistema,
que son los portadores de la información necesaria para conocer el problema y definir el
proyecto. Por otro lado, supone la identificación y descomposición 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 técnica:
Entrevista. Es una conversación 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 información principal y
de la relación 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 realización de una entrevista lo habitual es la toma de notas, para redactar más
tarde el informe de evaluación de la misma. Para la grabación 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, haciéndole sentir incómodo. Pese a su costo, se va
generalizando el uso de videoconferencias para la realización de entrevistas remotas, con
la consiguiente comodidad para ambas partes.
Toda entrevista requiere de una preparación previa: establecer los objetivos, seleccionar
al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir
documentación, elegir el tipo de preguntas para finalmente utilizar la información recabada
para lograr los fines.
Según 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 más 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 gustaría recibir de su sistema?
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 34
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 Especificación 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: Análisis del sistema. Consiste
en analizar los requisitos para centrarse en qué debe hacer el sistema.
Con el Análisis del sistema se pretende:
Organizar la información; es decir, reflejar la información del problema en un
formato gráfico, más fácil de manejar. Este formato hace que los requisitos sean
entendibles para el diseñador y, a la vez, facilita la comunicación 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 más fáciles de resolver.
Así pues, toda aplicación se apoya en tres pilares o consta de tres partes principales:
Procesos. Son la parte funcional de la aplicación. Reflejan las funciones o tareas
que debe realizar la aplicación, muestran cómo se transforman los datos.
Datos. Son la parte estática de la aplicación. Se refieren a la información que se
necesita almacenar.
Eventos. Son la parte dinámica de la aplicación. Muestran los aspectos del sistema
que cambian con el tiempo. Provocan la ejecución de la operación adecuada en
cada momento. Son los que activan la aplicación (la ponen en marcha) y propagan
esa activación a lo largo de la aplicación, desencadenando la ejecución de otras
operaciones. Los eventos llevan el control de la aplicación introduciendo el
dinamismo necesario para su ejecución. Los eventos tienen mucha relación con la
interfaz de la aplicación. Porque a través de la interfaz se introducen los eventos.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 35
Los procesos dicen qué hay que hacer.
Los datos indican con qué hay que hacerlo.
Y los eventos muestran cuándo hay que hacerlo.
Los tres pilares son complementarios, no tiene más importancia uno que otro, se
necesitan los tres. En algunos sistemas predomina más uno que otro, pero siempre están
presentes los tres.
Para especificar cada uno de los tres pilares se utilizan Modelos. Un Modelo es una
representación abstracta de la realidad. Por tanto, como resultado del análisis se
obtendrán:
Modelo de Procesos, de modelo de Datos y de modelo de Eventos
Modelo de Procesos: recoge qué funciones, actividades, tareas, acciones, debe
realizar la aplicación y cómo manejar los datos.
Modelo de Datos: describe la información que maneja la aplicación, los datos que
debe almacenar. Y muestra cómo organizarla.
Modelo de Eventos: Indica en qué momento debe ejecutarse cada acción. Para
construir cada modelo hay diferentes técnicas, algunas son complementarias.
Figura 2.1
En la fase de análisis se pretende que los modelos (de procesos, de datos y de eventos)
estén lo suficientemente detallados sin llegar a descender al diseño.
El análisis tiene por objetivo entender el problema: las necesidades del cliente, las
restricciones que se deben cumplir.
El diseño pretende obtener una solución óptima que cumpla todos los requisitos. Se
orienta hacia la máquina, centrándose en cómo crear un sistema software que reúna
todas las necesidades y cumpla todas las restricciones.
El levantamiento de requerimientos incluye tres tipos de actividad:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 36
Sacar requisitos: la tarea de comunicarse con los clientes y los usuarios para
determinarse cuáles son sus requisitos. Esto a veces también se llama acopio de
los requisitos.
Analizar requisitos: determinándose si los requisitos indicados son confusos,
incompletos, ambiguos, o contradictorios, y después resolviendo estas ediciones.
Requisitos de la grabación: 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. Análisis y diseño en un programa orientado a objetos
Con el fin de reflexionar sobre la asignatura, en el foro: Análisis y diseño en un
programa orientado a objetos construirás un concepto propio, tomando en cuenta los
temas abordados con anterioridad y los comentarios de tus compañeros. 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 análisis y diseño
Orientado a objetos.
3. Ingresa al foro, genera una nueva entrada y participa.
2.2. Documentación para levantamientos y especificaciones
La documentación reúne todas las actividades dedicadas básicamente a planificar el
proceso de ADOO y mantener los documentos necesarios para los desarrolladores y los
usuarios. El esquema formal que debe tener una especificación de requisitos es el
siguiente:
1. Índice
2. Descripción del ámbito y alcance del proyecto
3. Lista de usuarios participantes
4. Descripción del sistema actual
5. Catálogo (priorizado) de requisitos del sistema
a. Funcionales
b. No funcionales
i. Restricciones
ii. De funcionamiento
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 37
* Del sistema
* Requisitos software
* Requisitos hardware
iii. Manejo de excepciones
6. Análisis de alternativas
a. Descripción de la alternativa 1
b. Descripción de la alternativa 2
c. Descripción detallada de la alternativa seleccionada
i. Modelo lógico de procesos
ii. Análisis costo-beneficio
iii. Diferencias significativas con las demás alternativas
7. Apéndices (si es necesario)
2.2.1. Documentación
La documentación de los requerimientos, es una de la parte importante durante en el
análisis. En la práctica es común describir los requerimientos en un documento, llamado
especificación de requerimientos del software, su principal objetivo es de comunicar de
forma efectiva los requerimientos, objetivos del dominio.
En primera instancia la documentación contiene la información que aporta el cliente que
encarga la aplicación, contiene todos los registros de las reuniones de trabajo del grupo
de análisis.
Documentos básicos de análisis orientado a objetos:
Documentos de análisis
Especificación de requisitos o requerimientos
Diagramas de casos de uso
Escenarios y sub-escenarios
Prototipos y su evaluación
Todos los documentos deben estar identificados y codificados.
Identificación
Es necesario identificar todos los elementos del proceso de desarrollo de software de una
forma única.
El título debe reflejar de la mejor forma posible sus fines y su funcionalidad.
• Descripción
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 38
• Autores
• Versión. Notación decimal.
• Revisión. Autores
• Fecha
• Código de cada documento o diagrama
Documentos de análisis
Contiene la documentación que aporta el cliente que encarga la aplicación. También
contiene las actas de las reuniones de trabajo del grupo de análisis, es necesario un
secretario que tome acta y es necesario aprobar el acta de cada reunión por todos los
miembros.
2.2.2. Especificaciones
Expresa las características esenciales de un objeto, las cuales distinguen al objeto uno de
otro. A parte de distinguir los objetos también provee límites conceptuales, permitiendo
que se disponga de las características de un objeto que se necesite.
El objetivo principal de las especificaciones, es en entregar una especificación de
requisitos que ayuden a determinar de forma completa y correcta el diseño orientado a
objetos.
2.3. Estándares de Especificación
Las especificaciones del software determina el proceso de comprensión y definición
sobre los servicios que se requieren del sistema y de identificación de las restricciones de
funcionamiento y desarrollo del mismo. La ingeniería de requerimientos es un proceso
crítico en el proceso del software, los errores en esta etapa originan problemas
posteriores en el diseño e implementación del sistema.
En la siguiente figura se muestra el proceso de ingeniería de requerimientos. Éste
conduce a la producción de un documento de requerimientos, que es la especificación del
sistema. Normalmente en este documento los requerimientos se presentan en dos niveles
de detalle. Los usuarios finales y los clientes necesitan una declaración de alto nivel de
los requerimientos, mientras que los desarrolladores del sistema necesitan una
especificación más detallada de éste.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 39
Figura 2.2
2.3.1. Fases de la estandarización
Existen cuatro fases principales en el proceso de estándares de ingeniería de
requerimientos:
1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer
con las tecnologías 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
económico de elaborar. EI resultado debe informar si se va a continuar con un análisis
más detallado.
2. Obtención y análisis de requerimientos. Es el proceso de obtener los requerimientos
del sistema por medio de la observación de los sistemas existentes, discusiones con los
usuarios potenciales y proveedores, el análisis de tareas, etcétera. Esto puede implicar el
desarrollo de uno o más modelos y prototipos del sistema que ayudan al analista a
comprender el sistema a especificar.
3. Especificación de requerimientos. Es la actividad de traducir la información
recopilada durante la actividad de análisis 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
descripción más detallada de la funcionalidad a proporcionar.
4. Validación de requerimientos. Esta actividad comprueba la veracidad, consistencia y
completitud de los requerimientos. Durante este proceso, inevitablemente se descubren
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 40
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 análisis de requerimientos continúa durante la
definición y especificación, y a lo largo del proceso surgen nuevos requerimientos. Por lo
tanto, las actividades de análisis, definición y especificación se entrelazan. En los
métodos ágiles como la programación extrema, los requerimientos se desarrollan de
forma incremental conforme a las prioridades del usuario, y la obtención de
requerimientos viene de los usuarios que forman parte del equipo de desarrollo.
2.3.2. Análisis de restricciones
Las restricciones son relaciones entre entidades de un modelo de objetos, el término de
entidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restricción
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 después 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 específicos 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 número de control.
Las restricciones simples pueden situarse en el modelo de objetos, restricciones
complejas aparecerán en el modelo funcional. Las restricciones no tienen por qué
aparecer inicialmente en el modelo de objetos, estas irán añadiéndose conforme se vaya
concretando en la definición del modelo.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 41
Actividad 2. Requerimientos, fases y restricciones para diseñar un
programa
Con el fin de aplicar cada uno de los conceptos básicos de los estándares de
especificaciones de un análisis, diseña un programa con orientación a objetos haciendo
un documento que sirva como base para conocer los requerimientos para diseñar un
programa para un salón de belleza.
1. Plantea una situación hipotética o ve a preguntar a un salón de belleza con el
encargado o encargada acerca de qué le gustaría controlar por computadora (Obtención y
análisis de requerimientos).
2. En un archivo de texto escribe los requerimientos del usuario y del sistema, de
acuerdo a lo recabado en la entrevista (Especificación de requerimientos).
3. Apunta si es viable o no (Validación de requerimientos).
4. Guarda la Actividad con el nombre DOO_U2_A2_XXYZ. Donde XX son es apellido(s) y
YY nombre(s).
5. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
2.4. Modelos del desarrollo del software
Las metodologías se centra en una serie de combinaciones de los modelos de proceso
genéricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodología debe
definir con precisión los roles y actividades involucradas, junto con prácticas, guías de
adaptación.
Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías
asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo,
por ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la
diversidad de propuestas y diferencias en el grado de detalle, información 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 análisis y diseño,
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 42
podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y
Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de
desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del
proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de
Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o
Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más
orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a
equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos
asociados al trabajo en equipo e involucran activamente al cliente en el proceso.
Los métodos estructurados comenzaron a desarrollarse a fines de los 70‟s con la
Programación Estructurada, luego a mediados de los 70‟s aparecieron técnicas primero
para el Diseño (por ejemplo: el diagrama de Estructura) y posteriormente para el Análisis
(por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente
apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta
generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia),
MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos
estructurados en el ámbito académico: Gane &Sarson, Ward &Mellor, Yourdon&DeMarco
e InformationEngineering.
Metodologías orientadas a objetos, va unida a la evolución de los lenguajes de
programación orientada a objeto, los más representativos: a fines de los 60‟s SIMULA, a
fines de los 70‟s Smalltalk-80, la primera versión de C++ por BjarneStroustrup en 1981 y
actualmente Java o C# de Microsoft. A fines de los 80‟s comenzaron a consolidarse
algunos métodos Orientados a Objeto
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de
conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a
un objetivo más modesto, para dar lugar al UnifiedModelingLanguage (UML), la notación
OO más popular en la actualidad (Booch-Grady, 1996)).
Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE
(Jacobson), Coad&Yourdon, Shaler&Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son:
RationalUnifiedProcess (RUP), OPEN, MÉTRICA (que también soporta la notación
estructurada).
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 43
2.4.1. Ágiles
Nuevas técnicas para aplicar las prácticas esenciales de la programación extrema y
métodos ágiles para desarrollar sistemas orientados a objetos se encuentre la
metodología ágil. Es cuando el desarrollo de software es incremental (entregas pequeñas
de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil
de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de
último momento)
El modelado ágil también abarca un conjunto de principios esenciales. Además delos
principios esenciales de la programación extrema, el modelado ágil agrega principios tales
como "modelar con un propósito", "el software es su meta principal" y "viajar con poco
equipaje", una forma de decir que poca documentación es suficiente.
Entre las metodologías ágiles identificadas:
• Extreme Programming
• Scrum
• Familia de Metodologías Crystal
• Feature Driven Development
• ProcesoUnificado Rational, unaconfiguraciónágil
• Dynamic Systems Development Method
• Adaptive Software Development
• Open Source Software Development
2.4.2. Predictivos
Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación
durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o
clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción
del sistema.
Todas las propuestas metodológicas antes indicadas pueden considerarse como
metodologías tradicionales por el especial énfasis que presenta en cuanto a su
adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse),
realizando una configuración adecuada, podría considerarse Ágil.
La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o
mecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Los
ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 44
construir y cómo deben juntarse estas cosas. Muchas decisiones de diseño, 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
compañía diferente, para ser construidos. Se supone que el proceso de la construcción
seguirá los dibujos. En la práctica los constructores se encuentran con algunos
problemas, pero éstos son normalmente poco importantes.
Como los dibujos especifican las piezas y cómo deben unirse, actúan como los
fundamentos de un plan de construcción 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 construcción razonablemente predecibles. También
dice en detalle cómo deben hacer su trabajo las personas que participan en la
construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque
se necesita a menudo mucha habilidad manual.
Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño,
que es difícil de predecir y requiere personal caro y creativo, y la construcción que es más
fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una
vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una
manera más predecible. En ingeniería civil la construcción es mucho más costosa y
tardada que el diseño y la planeación.
Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible
que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la
construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software
de modo que la construcción pueda ser sencilla una vez que el plan esté hecho.
¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño
como el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones
significativas usando UML, podemos armar un plan de construcción y entonces podemos
dar planes a los programadores como una actividad de construcción.
Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de
convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la
construcción suficientemente grande en costo y tiempo para hacer valer la pena este
enfoque?
Todo esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es
conseguir un diseño UML en un estado que pueda entregarse a los programadores. El
problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero
resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros
civiles usan están basados en muchos años de práctica guardados en códigos
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 45
ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas,
son dóciles al análisis matemático. La única verificación que podemos hacer con los
diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que
sólo se descubren durante la codificación y pruebas. Incluso los diseñadores
experimentados se sorprenden a menudo cuando convierten dichos diseños 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 construcción.
En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Se
sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas
unitarias, una inversión casi perfecta de las proporciones de la construcción del puente.
Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50%
del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software
comparado con su papel en otras ramas de la ingeniería.
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).
3. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 46
Autoevaluación
Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
primera unidad del curso, es necesario que resuelvas la actividad integradora. Recuerda
que es muy importante leer cuidadosamente los planteamientos indicados y elegir la
opción adecuada para cada uno.
Evidencia de aprendizaje. Requerimientos para diseñar un programa
Orientado a Objetos
Como parte de la evaluación de esta unidad, debes llevar a cabo una actividad cuyo
propósito es conceptuar el proceso.
1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con los
estándares para diseñar un programa con OO para el control de una papelería 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.
4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
Cierre de la unidad
Has concluido la unidad 2 del curso a lo largo de esta trabajaste con la documentación de
requerimientos para el análisis orientado a objetos, comenzando con la parte de
levantamiento de requerimientos, que incluye el describir cuáles son los requerimientos y
que actividades necesitas realizar para el levantamiento de los mismos.
También identificas cual es la documentación para el levantamiento y que
especificaciones debe cumplir considerando sus estándares, divididos en sus fases y
análisis de restricciones. Por último en esta unidad debes distinguir que modelos del
desarrollo de software se manejan y si son ágiles o predictivos.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 47
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 tú caso, ya
estás preparado(a) para seguir con la unidad 3, en donde continuarás con la
Metodologías de Diseño para la Generación 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 Análisis y Diseño Orientado a Objetos.
Fuentes de consulta
Booch-Grady (1996) Análisis y Diseño Orientado a Objetos con aplicaciones. México:
Pearson Educación.
Cueva, J. (2005) Ingeniería del Software. Madrid: Pearson Educación.
Cueva, J. (2005) Análisis 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 metodología. Traducción de Alejandro Sierra para
programacionextrema.org. Recuperado el 22 de julio de 2011 de:
http://www.programacionextrema.org/articulos/newMethodology.es.html
García, S. y Morales, E. (2003) Desarrollo de aplicaciones informáticas. Análisis y
diseño detallado de aplicaciones informáticas de gestión. México: Ed. Thompson.
Kendall, E. (2005) Análisis y Diseño de sistemas. México: Pearson Educación.
Letelier, P. y Penadés, M. (s/f) Metodologías ágiles para el desarrollo de software:
eXtremeProgramming (XP). Universidad Politécnica de Valencia. Recuperado el 22
de julio de 2011 de: http://www.willydev.net/descargas/masyxp.pdf
WorldLingo (2011) Análisis de requisitos. WorldLingoTranslations LLC. Recuperado el
22 de julio de 2011 de:
http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 48
Unidad 3. Metodologías de diseño para la generación de sistemas
orientados a objetos
Presentación de la unidad
En las metodologías de análisis y diseño orientado a objetos, se utilizan algunos
conceptos que se definen a continuación.
Método. Es un conjunto de lineamientos y reglas, incluyendo los siguientes
componentes.
Conceptos de modelado. Permiten la captura de la semántica y el conocimiento
acerca de un problema y su solución.
Modelo es una representación formal de un sistema con cierto nivel de
abstracción. En las etapas de especificación de requerimientos y análisis el nivel
de abstracción normalmente es alto, omitiendo detalles de implementación.
Meta modelo. Es un modelo que describe otros modelos, describe los conceptos
del método modelo y sus relaciones, define los modelos legales que pueden ser
construidos dentro del método, describe la información que debe ser capturada.
Vistas y notaciones. Son útiles en la presentación fundamental del modelo de
información para que los seres humanos puedan comprenderla, examinarla y
modificarla en su caso.
Una vista solo muestra una parte de la semántica del modelo y diferentes vistas
pueden presentar la misma información en varias formas.
Notación. Permite construir, examinar y manipular modelos, el mismo modelo se
puede dibujar de diferentes maneras mediante el uso de diferentes símbolos,
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
construcción e implementación de modelos. El proceso puede estar distribuido en
varios niveles de detalle, desde el nivel más alto del proyecto, hasta etapas
específicas para la construcción de modelos de bajo nivel. El proceso indica qué
modelos se deberán construir y cómo construirlos.
Proceso. Es la guía 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 iteración dentro de él. A bajo nivel describe un esqueleto de trabajo
para la producción de modelos; las etapas para la construcción del modelo,
lineamientos para describir componentes de él, principios de diseño a seguirse,
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 49
mediciones de calidad, referencias cruzadas, reglas de consistencia y banderas
rojas para identificar posibles problemas.
Patrón. Es una solución estándar escrita para resolver un problema, basada en
una secuencia de tiempo. No existen museos de programas donde los nuevos
diseñadores puedan aprender, emulando programas que allí existen, mas bien,
tratan de captar ideas de los diseñadores expertos. Actualmente existe un
Movimiento de Patrones con el propósito de coleccionar, catalogar y explicar
patrones útiles de diseño, de tal forma que otros diseñadores puedan aprender de
ellos. Por lo tanto, Los Patrones son resúmenes de casos de diseño basados en la
experiencia.
Reglas de Diseño. Son estados o propiedades que deberán llevarse a cabo u
omitirse en un diseño o estrategias generales de diseño 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 métodos AOO/DOO existen dos tipos principales, dividiendo a estos en:
Estáticos (enfocados a datos), lo importante es la estructura de datos anexa a los
objetos y las operaciones que sobre ella operan.
Dinámicos (enfocados a comportamientos o enfocados a responsabilidades): un
objeto tiene sentido en estos métodos cuando exhibe un comportamiento
diferencial respecto del resto delos objetos.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 50
En la tabla anterior se mezclan métodos de análisis y de diseño porque, pese a lo que
anuncien sus autores o aun su mismo nombre, la distinción entre análisis y diseño se
difumina, aquí presentamos los más utilizados y que dieron origen al que actualmente se
utiliza para el ADOO.
Propósito
Con el transcurso de esta unidad ubicarás las diferentes metodologías para el diseño de
sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /
Ingeniería de software orientado a objetos), OMT (Object Modeling Technique / Técnica
de modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado de
Modelado) las cuales nos servirán después de hacer un análisis para hacer un buen
diseño apoyado con estas técnicas.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 51
Competencia específica
Comparar las metodologías de diseño para la generación de sistemas orientados a
objetos mediante los diagramas con los métodos de modelado Booch, OOSE, OMTy
UML.
3.1. Booch
Es una metodología que se utiliza en el análisis y diseño de software creada por Booch
durante su estancia en Rational Software Corporation.
El método BOOCH define modelos para describir un sistema, soportando el desarrollo
iterativo e incremental. El método incluye diferentes diagramas según el enfoque que se
le dé ya sea:
De clases
De objetos
De transición de estados
De módulos
De procesos
De interacción
3.1.1. Introducción
El método cuenta con una notación expresiva y bien definida que le permite al diseñador
expresar sus ideas y concentrarse en problemas más serios.
Son necesarias dos dimensiones para especificar la estructura y comportamiento de un
sistema orientado a objetos:
• Dimensión uno: Física / Lógica.
• Dimensión dos: Estática / Dinámica.
Para cada dimensión 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 proyección de estos modelos. En el estado
estable, todos estos diagramas deben ser consistentes con el modelo y también
consistentes entre ellos mismos.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 52
Dimensión lógica: 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.
Dimensión física: Describe la composición concreta en cuanto a hardware y software del
contexto o implantación del sistema.
Dimensión estática: Están formados por los diagramas de:
1.- Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visión
lógica de un sistema, utilizada en la etapa de análisis.
2.- Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa
de diseño lógico de un sistema.
3.- Diagramas de módulos: Muestran la asignación de clases y objetos a módulos en el
diseño físico de un sistema.
4.- Diagramas de procesos: Muestran la asignación de procesos a procesadores en el
diseño físico de un sistema.
Dimensión dinámica: La semántica dinámica de un problema se expresa mediante los
siguientes diagramas:
1.-Diagrama de transición de estados: Muestra el comportamiento de cada instancia de
una clase, los eventos que provocan una transición 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 interacción: Muestra el orden temporal en que se suceden los mensajes
en un conjunto de objetos que representan un escenario. Están 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 visión lógica de un sistema. Los dos elementos esenciales de un diagrama de clases
son: las clases y sus relaciones básicas.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 53
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 diseño 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 algún servicio proporcionado por la clase, se distinguen de los
atributos añadiendo paréntesis.
N() Nombre de la operación solamente.
R N(Argumento) Clase de retorno de la operación, nombre y parámetros formales (si los
hay).
Las relaciones de clase representan una colaboración con otras clases de diversas
maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones:
Figura 3.2. Conexiones entre clases
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 54
La asociación conecta dos clases y denota una conexión semántica, se etiquetan con
expresiones sustantivas, denotando la naturaleza de la relación.
La herencia denota una relación de generalización / especialización (una relación <<es
un>>), y aparece como una asociación con una cabeza de flecha. La flecha apunta a la
superclase, y el extremo opuesto de la asociación designa la subclase. La subclase
hereda la estructura y comportamiento de su superclase. Las relaciones de herencia no
pueden llevar indicaciones de cardinalidad.
La Posesión: denota una relación todo / parte (relación <<tiene un>> o agregación),
aparece como una asociación con un círculo relleno en el extremo que señala al
agregado, la clase que está en el otro extremo denota la parte cuyas instancias están
contenidas por el objeto agregado.
La Utilización: denota una relación cliente / servidor y aparece como una asociación con
una circunferencia en el extremo que denota al cliente. En esta relación de alguna forma
el cliente depende del servidor para que éste le proporcione determinados servicios.
Figura 3.3. Utilización
Diagramas de Objetos
Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones
en el diseño lógico 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, también se pueden
especificar algunos atributos del objeto.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 55
Figura 3.4. Objeto
Relaciones entre objetos: los objetos interaccionan a través de sus enlaces con otros
objetos, un enlace es una instancia de una asociación, 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 dirección que un mensaje o en
dirección contraria. El mostrar explícitamente la dirección del flujo de datos ayuda a
explicar la semántica de un escenario particular.
Objetos activos: son aquellos que incorporan su propio hilo de control.
Figura 3.6. Objetos activos
Diagramas de módulos
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 56
Se utiliza un diagrama de módulos para mostrar la asignación de clases y objetos a
módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una
vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un
diagrama de módulos son los módulos y sus dependencias.
Programa principal: Denota un archivo que contiene la raíz del programa.
Especificación y cuerpo: Denotan archivos que contienen la declaración y la definición de
las entidades.
Subsistema: Los subsistemas sirven para modularizar el modelo físico de un sistema. Un
subsistema es un agregado que contiene otros módulos y otros subsistemas. Cada
módulo engloba la declaración o definición de clases, objetos y otros detalles del lenguaje.
Dependencias: la única relación que puede darse entre dos módulos es una dependencia
de compilación, representada por una línea dirigida que apunta al módulo 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 asignación de procesos a procesadores
en el diseño físico 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 líneas no dirigidas para indicar conexiones entre procesadores y/o
dispositivos.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 57
Figura 3.7. Diagrama de procesos
El proceso de diseño orientado a objetos no puede describirse mediante reglas, aunque
está bastante bien definido como para brindar un proceso predecible y repetible para una
organización 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
económica, entregado en tiempo, y es flexible al cambio y al crecimiento.
3.2. OOSE
Este método 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 análisis, construcción y prueba.
OOSE presenta cinco técnicas para modelar un sistema:
Modelo de requerimientos: delimita el sistema y define su funcionalidad.
Modelo de análisis: estructura el sistema, modelando tres tipos de objetos (objetos
de interface, objetos entidad y objetos de control).
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 58
Modelo de diseño: refina el modelo de análisis y lo adapta a un ambiente de
implementación. Consiste de diagramas de interacción y diagramas de transición
de estados.
Modelo de implementación: consiste en el código fuente de los objetos
especificados en el modelo de diseño.
Modelo de prueba: es llevado a cabo mediante la realización de pruebas al modelo
de implementación.
La idea básica de estos modelos es capturar el concepto inicial de todos los
requerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre ellos
es importante. Para ser posible el mantenimiento del sistema es también necesario que
los modelos sean tangibles.
3.2.1. Introducción
Este método proporciona un soporte para el diseño creativo de productos de software,
inclusive a escala industrial. El autor plantea el problema del diseño y construcción de
software haciendo una comparación con la industria de la construcción, contemplando las
siguientes fases:
Herramientas. Soportan todos los aspectos de la empresa, explícitamente las
actividades de arquitectura, métodos y procesos.
Procesos. Permite el escalamiento de los métodos, de tal forma que puedan ser
aplicados a proyectos de forma interactiva y en partes.
Métodos. Establece de manera explícita los procedimientos etapa por etapa que
deben seguirse para aplicar la arquitectura al proyecto.
Arquitectura. Una buena estructura del sistema es fácil de entender, de cambiar y
realizar pruebas y mantenimiento. Las propiedades del sistema determinan cómo
la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la
arquitectura son extremadamente importantes y forman la base del método.
Diseño creativo. Las actividades creativas de un desarrollo, consisten en la
transformación de un conjunto de requerimientos y nociones vagas, en un plan
estructurado de construcción y un plan de acción para su implementación .El diseño
creativo tomando como referencia una base arquitectónica es seguir paso a paso los
métodos y procesos con la asistencia de herramientas, para convertir los requerimientos
dentro de una arquitectura viable para la construcción de un proyecto incluyendo la
creación de prototipos.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 59
Un aspecto importante durante el desarrollo del sistema, es considerar explícitamente el
proceso de cambio.
Todos los sistemas cambian durante su ciclo de vida. Hoy en día el desarrollo de los
nuevos métodos 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
incorporándose en nuevas versiones.
La primera versión de un sistema representa una pequeña parte de una composición
durante el ciclo de vida del sistema.
Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva
versión 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 análisis. Especifica el comportamiento funcional del sistema bajo
prácticamente circunstancias ideales y sin hacer alusión a un ambiente particular de
implementación.
Construcción. La primera actividad en la construcción consiste en la implementación de
los detalles que conciernen a la arquitectura y construcción del plan, que es ir de una
mayor abstracción a concretizar más el plan.
Diseño. Formaliza el modelo de análisis en términos del ambiente de implementación y
especifica la identidad de los bloques de construcción.
Prueba del sistema. Consiste en la verificación del trabajo de cada uno de los paquetes
de servicio definidos en el modelo de análisis Esta fase tiene lugar en varios niveles,
desde funciones específicas, hasta el sistema completo.
Desarrollo incremental. El desarrollo del sistema es usualmente un proceso el cual toma
varios años para su terminación. La especificación es seguida por el análisis, la
construcción y prueba del sistema completo. Este método puede trabajar si todos los
requerimientos del sistema son conocidos del conjunto de salida.
En la mayoría de los casos, conviene mejor desarrollar el sistema etapa por etapa,
empezando con unas cuantas funciones principales, como se va aclarando la
comprensión del sistema en cuanto a su funcionalidad se van agregando nuevas
funciones, de esta forma el sistema va creciendo.
Sistema de desarrollo y metodología. Cuando se desarrolla un sistema grande es
importante conocer cómo cada uno de los pasos del método interactúa y cómo ellos
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 60
compiten dentro del desarrollo del proceso. Se hace hincapié en la discusión entre el
proceso de desarrollo y las ideas básicas que hay detrás del método lo que determina la
selección 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 consideración. Se trabaja con 5 modelos:
1. El modelo de requerimientos: El objetivo es la captura de requerimientos
funcionales.
2. El modelo de análisis: El objetivo es dar al sistema una estructura de objetos
robusta y flexible a los cambios.
3. Modelo de diseño: Tiene como objetivo adoptar y refinar la estructura de objetos
en el ambiente actual de implementación.
4. El modelo de implementación: Tiene como objetivo implementar el sistema.
5. El modelo de prueba: Su objetivo es verificar el sistema.
La idea básica de estos modelos es capturar el concepto inicial de todos los
requerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre ellos
es importante. Para hacer posible el mantenimiento del sistema es también necesario que
los modelos sean tangibles.
Modelo de requerimientos
Actores y Casos de Uso
La primera transformación hecha de la especificación de requerimientos para el modelo
de requerimientos consiste en:
Un modelo de caso de uso
Descripción de la interface
Un modelo en el dominio del problema
Figura 3.8. Modelo de caso de uso
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 61
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é debería ser hecho por el
sistema (caso de uso).
Los actores representan quienes interactúan con el sistema. Representan todas las
necesidades de cambio de información con el sistema. Dado que el actor representa la
parte exterior del sistema no se describirán 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 análisis
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 información para este sistema se enfoca en la captura de:
Información: Especifica la información de ayuda en el sistema. Así como describe
el estado interno del sistema.
Comportamiento: Especifica el comportamiento que adopta el sistema. Especifica
cuándo y cómo el sistema cambia de estado.
Presentación: Detalla la presentación del sistema al mundo exterior.
Figura 3.9. Dimensiones del modelo de análisis
Existen varios tipos de objetos usados para la estructura del sistema en el modelo de
análisis
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 62
Figura 3.10. Tipos de objeto
Cada objeto al menos captura dos de las tres dimensiones del modelo de análisis, sin
embargo cada uno de ellos tiene cierta inclinación hacia una de las dimensiones.
Figura 3.11. Dimensiones del modelo de análisis
El modelo de diseño
El proceso de construcción edifica el sistema usando tanto el modelo de análisis y el
modelo de requerimientos. Primero se crea el modelo de diseño que es un refinamiento y
formalización del modelo de análisis. Al inicio del trabajo cuando se desarrolla el modelo
de diseño es para adaptarlo a la implementación del ambiente actual.
Figura 3.12. Implementación del ambiente
Una diferencia entre el modelo de análisis y el modelo de diseño es que el modelo de
análisis debe ser visto como un modelo conceptual o lógico del sistema, y el modelo de
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 63
diseño contiene el código, por lo cual el modelo de diseño deberá ser una representación
de la manera como el código fuente es estructurado, manejado y escrito.
Figura 3.13. Consecuencias del ambiente
El modelo de Implementación
La implementación del modelo consiste de la notación del código. La información de
espacio es la opción del lenguaje de programación que se usa. No necesariamente se
requiere de un lenguaje de programación orientada a objeto, sin embargo, si se
recomienda el uso de un lenguaje de programación orientada a objeto, desde la
concepción inicial hasta la construcción. La base para la implementación es el modelo de
diseño. Aquí se especifica la interface década 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 abstracción de algo, con la finalidad de comprenderlo, antes de
construirlo, ya que un modelo omite los detalles no esenciales, es más sencillo
manejarlos, que manejar la entidad original.
Esta técnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos
modelo dinámico y modelo funcional.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 64
3.3.1. Introducción
El modelo de objetos. Es el modelo más 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 estática del sistema. El modelo de objetos se representa
mediante un diagrama de clases.
El modelo dinámico. 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 función" del
sistema, mediante la transformación de valores de los datos. Se representa mediante un
diagrama de flujo.
Cada modelo describe un aspecto del sistema pero contiene referencias a los demás
modelos. Lo cual indica que los tres no son totalmente independientes.
Pasos del proceso de desarrollo orientado a objetos:
Conceptualización: Se describen los requerimientos para la solución del sistema.
Comienza identificando las necesidades desde el punto de vista de los usuarios. Dicha
información puede ser extraída de los casos de uso y del dominio del problema.
Análisis: Entender y modelar el problema en el dominio de la aplicación.
Diseño del sistema: Determinar la arquitectura del sistema en términos de subsistemas.
Diseño de objetos: Refinar y optimizar el modelo de análisis, agregando conceptos de
programación.
Código: Implementar las clases de objetos en un lenguaje de programación.
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 abstracción hasta llevarlo a un nivel de detalle que
finalmente representa la solución del problema.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 65
3.3.2. Modelos
Los pasos para construir el modelo de objetos son los siguientes:
1. Identificación de objetos y/o clases.
2. Crear un diccionario de datos.
3. Identificación de las asociaciones y agregaciones entre los objetos.
4. Identificación de atributos y enlaces.
5. Organización y simplificación de las clases empleando herencia.
6. Verificación de las vías 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 módulos.
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 términos
del dominio del problema. Además 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 rectángulo 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 comprensión
del sistema, entonces el rectángulo solo se queda con el nombre de la clase.
Modelo dinámico = Diagrama de estados + diagrama global de flujo de sucesos.
Escenario:
Es la representación escrita de los casos de uso y de la interacción de los actores con
ellos para especificar el propósito del sistema.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 66
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
transición, cada transición 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 condición se puede pensar como una protección en las transiciones,
debido a que si se cumple dicha condición la transición se dará y podrá pasar el objeto de
un estado a otro, si dicha condición no se cumple inclusive podría pasar a otro estado
mediante otra transición o quedarse en el estado receptor hasta que la condición se
cumpla.
Acción: Es una operación que va asociada a un suceso y se representa mediante una
barra “/” y el nombre de la acción, después del nombre de la transición.
Modelo Funcional = Diagrama de flujo de datos + restricciones. Mediante el modelo
funcional se puede observar los resultados que se tienen de un cálculo de valores,
especificando solamente entradas y salidas de los valores, mas no como son calculados
estos. El modelo funcional consta básicamente de diagramas de flujo de datos. Los
diagramas de flujo de datos son grafos que muestran el flujo de valores de datos a través
de procesos los cuales modifican dichos valores para transformarlos en otros. Los
diagramas de flujo están compuestos de:
Procesos
Flujos de datos
Actores
Almacenes
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 67
Procesos: se representan mediante una elipse, los procesos tienen como entrada datos,
los cuales serán transformados, por lo cual un proceso es visto como un método de una
operación 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. Además de trasladar los datos a otros procesos, los flujos de datos pueden
usarse para copiar un valor, realizar la composición de un agregado y así como su
inverso.
Actividad 1. Metodología para la generación de sistemas OO
La presente actividad tiene como propósito que reflexiones acerca de las metodologías
vistas hasta ahora cuál de ellas te parece la más adecuada a diseños orientado a objetos.
1. Retoma las lecturas de los temas 3.1. Booch, 3.2. OOSE y 3.3. OMT.
2. Identifica las metodologías y los modelos para diseñar con base en la Orientación a
Objetos.
3. Ingresa al foro y genera una nueva entrada.
3.4. UML
UML es una técnica desde en 1994 abarca aspectos de todos los métodos de diseño los
antecesores de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 68
del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 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, aeronáutica, finanzas, etc.
Los principales beneficios de UML son:
Mejores tiempos totales de desarrollo (de 50 % o más).
Modelar sistemas orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
Mejor soporte a la planeación y al control de proyectos.
Alta reutilización y minimización de costos.
3.4.1. Introducción
El lenguaje modelado unificado (UML) provee un sistema de arquitecturas trabajando con
objetos, análisis y diseño, con una buena consistencia del lenguaje para especificar,
visualizar, construir y documentar un sistema de software.
Esta especificación representa la convergencia de las mejores prácticas en la tecnología
de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos
derivado de las tres metodologías; (Booch, OMT y OOSE). Al conjuntar los métodos de
Booch, OMT y OOSE resulta un lenguaje de modelado potente para los usuarios de éstos
y otros métodos.
El UML da la idea que lo que se está haciendo, se realiza con métodos 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 información de los modelos.
Proporcionar mecanismos de extensibilidad y especialización para ampliar los
conceptos básicos.
Ser independiente de un lenguaje en particular y del proceso de desarrollo.
Proporcionar bases formales para la comprensión del Lenguaje de Modelado.
Integración en una mejor práctica.
El UML es un lenguaje de modelado que incorpora a la comunidad orientada a objetos el
consenso de los conceptos de modelado básico y permite desviaciones, las cuales se
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 69
expresan en términos de mecanismos de extensión. Es un conjunto preciso que consiste
en la definición de la semántica y notación del UML, definiendo también cómo se maneja
el Lenguaje de Especificación de Objetos.
Partiendo del hecho que el ser humano requiere de modelos para manejar sistemas
complejos, y en cuanto más complejos se vuelven los sistemas, es necesario tener
mejores técnicas de modelado. El contar con una metodología universal para el desarrollo
de sistemas de software es de gran beneficio en la construcción de todo tipo de sistemas.
Disponer de buenos modelos facilita la comunicación entre equipos de trabajo en un gran
proyecto.
El UML es un Lenguaje de Modelado Visual riguroso, y ya convertido en un estándar, es
la herramienta ideal para atacar el ciclo de vida de un proyecto de software utilizando la
tecnología Orientada a Objetos.
El documento describe los mecanismos de la notación para la representación visual del
UML.
Existen básicamente cuatro constructores gráficos usados en la notación del UML; iconos,
símbolos de 2 dimensiones, uniones y cadenas.
Icono. Es una figura gráfica de tamaño y forma definida, éstos pueden aparecer dentro del
área de los símbolos, en la terminación de una unión, etc.
Símbolos de 2 dimensiones. Son de tamaño variable, pueden contener listas de cadenas
u otros símbolos. Las uniones se conectan a los símbolos de 2 dimensiones como
terminación de la unión sobre alguna parte del contorno de dicho símbolo.
Uniones. Son segmentos de línea con sus extremos terminados en algún símbolo de 2
dimensiones.
Cadenas. Representan conceptos, pueden existir como un elemento dentro de un símbolo
o dentro de un compartimiento de un símbolo, como elementos de una lista, como
etiquetas de un símbolo o unión, o como un elemento estándar dentro de un diagrama.
El documento está dividido en varios capítulos de acuerdo a los conceptos semánticos, o
por los diferentes tipos de diagramas. Cada capítulo está subdividido por los elementos
que conforman el diagrama, y para cada elemento se cuenta con las siguientes
secciones:
El nombre de la notación a describir
Semántica
Notación
Mapeo
Opciones de presentación
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 70
Cada punto cuenta con su propia descripción:
Nombre de la notación: Especifica el nombre de la notación
Semántica: Es un breve resumen de la semántica para dicho elemento.
Notación: Explica la representación dotacional de la semántica mediante un diagrama.
Obviamente para cada caso se utilizan un diagrama diferente que proporciona la
identificación de la semántica del grafo especificado.
Mapeo: Indica cómo la notación puede ser representada como información semántica. Es
decir qué tipo de diagrama se utiliza, con cuáles rutas se maneja y cómo trabaja una
estructura conectada con otra estructura dentro de un mismo diagrama. Dando así el
sentido de saber interpretar la notación que se presenta y con qué fin es utilizada.
Opciones de presentación: Son herramientas que pueden ser utilizadas para dar más
énfasis a la notación cuando ésta lo requiera dejándola más completa y estructurada. En
varios elementos esta sección no se presenta debido a que no tiene opciones de
presentación.
3.4.2. OCL (Lenguaje de Especificaciones de Objetos)
El Lenguaje de Especificación 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
características de un lenguaje de expresión, de un lenguaje de modelado y de un lenguaje
formal.
El OCL es un lenguaje de expresión puro. Por lo tanto, garantiza que una expresión 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 expresión OCL, aun
cuando una expresión OCL puede usarse para especificar un cambio de estado, por
ejemplo, en una post-condición.
Todos los valores, de todos los objetos, incluyendo todos los enlaces, no cambiarán,
cuando una expresión OCL es evaluada, simplemente devuelve un valor.
El OCL no es un lenguaje de programación, por lo tanto, no es posible escribir lógica 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.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 71
Como el OCL es un lenguaje de modelado, toda consideración de implementación está
fuera de su alcance, y no puede ser expresada en el lenguaje OCL. Conceptualmente,
cada expresión OCL es atómica. El estado de los objetos en el sistema no puede variar
durante la evaluación.
OCL es un lenguaje formal donde todos los constructores tienen un significado
formalmente definido, la especificación 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 propósitos:
Para especificar características estáticas sobre clases y tipos en un modelo de
clases.
Para especificar características estáticas de tipo para Estereotipos.
Para especificar pre y post-condiciones sobre Operaciones y Métodos.
Como lenguaje de navegación.
Para especificar restricciones sobre operaciones:
Dentro del documento Semántica del UML, el OCL es usado en la sección
reglas bien formuladas, como constantes estáticas sobre la meta-clase en la
sintaxis abstracta. En varios lugares también es usado para definir
operaciones „adicionales‟, que son tomadas en cuenta en la formación 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 Métodos como a Operaciones.
Actividad 2. Cuadro comparativo de las diferentes metodologías
La presente actividad tiene la finalidad de que apliques cada uno de los conceptos
básicos de las metodologías de diseño vistas hasta ahora y además, que investigues las
fechas en las que implementaron dichas metodologías.
1. Investiga las fechas en que fueron implementadas las metodologías OO.
2. En un archivo de texto, elabora un cuadro comparativo donde incluyas las
características de cada una de las metodologías OO y la fecha en que fueron
implementadas.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 72
3. Guarda la Actividad con el nombre ADOO_U3_A2_XXYZ donde XX es apellido(s) .y
YY es tu nombre(s).
4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
Autoevaluación
Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
unidad 3 del curso, es necesario que resuelvas la autoevaluación. Recuerda que es muy
importante leer cuidadosamente los planteamientos indicados y elegir la opción adecuada
para cada uno.
Evidencia de aprendizaje. Cuadro comparativo de los métodos de
modelado
Como parte de la evaluación de esta unidad, lleva a cabo la siguiente actividad cuyo
propósito 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 conclusión donde expreses cuáles serían los
modelos más adecuados a utilizar en cada caso.
3. Consulta la Escala de Evaluación.
4. Guarda la evidencia con el nombre DOO_U3_EA_XXYY donde XX es tu apellido(s) y
YY tu nombre(s).
5. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
* Recuerda que de ser necesario y en base a los comentarios hechos por parte de tu
Facilitador(a), podrás enviar una segunda versión de tu actividad.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 73
Autorreflexiones
Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a)
presente, a partir de ellas, debes elaborar tu Autorreflexión en un archivo de texto llamado
DOO_U3_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta
Autorreflexiones.
Cierre de la unidad
Has concluido la unidad 3 del curso. A lo largo de ésta se recordaron las metodologías de
diseño para la generación de Sistemas Orientados a Objetos, tales como: Boosh, OOSE,
OMT, en cada uno de ellos se vio una breve introducción y su modelo. Por último el origen
de la metodología UML, la cual fue a través del OCL.
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
estás preparado(a) para seguir con la unidad 4, en donde continuarás con El diseño
orientado a objetos con UML, a través de la representación de objetos y clases con
diagramas y documentación para el diseño del software con UML, en dichos diagramas se
manejarán casos de uso, escenarios del caso de uso, diagramas de actividades,
secuencial, de clase y de gráfico de estado. Todo ello con el fin de obtener el prototipo
final al terminar el curso de Análisis y Diseño Orientado a Objetos.
Para saber más
En el siguiente documento encontrarás un ejemplo real de análisis aplicado al diseño de
un sistema escolar:
Desarrollo de un sistema de administración escolar académica para la escuela
“Cristóbal Colón” bajo plataforma web:
http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 74
Fuentes de consulta
Booch-Grady (2009) Análisis y Diseño Orientado a Objetos con aplicaciones.
México: Pearson Educación.
Fowler, M. & Scott, K. (1999) UML GOTA A GOTA México: Addison Wesley
Graham, I. (2002) Métodos Orientados a Objetos México: Addison Wesley/Díaz de
Santos.
Jacobson, I. (1992) Object-Oriented Software Engineering A Use Case Driven
Aproach México: Addison-Wesley
James, R., Blaha, M., Premerlani, W. & Eddym, F. (1990) Object Oriented
Modeling and Design. México: Pretice Hall.
Larman, C. (2004) Applying UML and Patterns An Introduction to object-Oriented
Analysis and Design México: Prentice Hall
Martin, J. & Odell, J. (1990) Análisis y Diseño Orientado a Objetos México:
Prentice Hall Iberoamericana.
Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML
México: Addison Wesley
Wirfs, R. & Wiener, L. (1990). Designing Object Oriented Softwarem. México:
Pretince Hall.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 75
Unidad 4. Diseño orientado a objetos con UML (Lenguaje Unificado de
Modelado)
Presentación de la unidad
El lenguaje unificado de modelado (UML) brinda un sistema de trabajo con objetos,
basado en el análisis y diseño, con una consistencia del lenguaje para especificar,
construir y documentar un sistema de software.
Esta especificación representa la convergencia de las mejores prácticas en la tecnología
de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos
derivado de las tres metodologías (Booch, OMT y OOSE).
El UML es un lenguaje de modelado que integra a la comunidad orientada a objetos los
conceptos de modelado básico y permite desviaciones, las cuales se expresan en
términos de mecanismos de extensión. Es un conjunto preciso que consiste en la
definición de la semántica y notación del UML, definiendo también cómo se maneja el
Lenguaje de Especificación de Objetos.
Propósito
Con el uso constante de UML se podrá lograr una mejor comprensión 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 más clara y precisa.
Así, al terminar el análisis y diseño se tienen de forma precisa y detallada las
especificaciones de clases y objetos, evitando el costo de una mala planeación en el
comienzo.
Competencia específica
Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos mediante el
método de modelado UML.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 76
4.1. Representación de objetos y clases con UML
En el diseño orientado a objetos todo se presenta través de objetos y clases. Por lo
general cuando se diseña una clase no es necesario mostrar todos los atributos ni todas
sus operaciones, basta con mostrar los subconjuntos más relevantes para organizarlos.
Un objeto, como recordarás, es la unidad mínima en la representación de algo real, y una
clase es un objeto con atributos y métodos o comportamientos.
4.1.1. Representación 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 esquemática con los atributos y operaciones
suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la
siguiente figura se ve cómo una misma clase puede representarse a distinto nivel de
detalle, según interese, y según la fase en la que se esté.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 77
Figura 4.1. Representacion de clases con diferentes tipos de detalles
4.1.2. Representación 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 específico, entonces sólo aparece el nombre de la
clase.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 78
Figura 4.2. Representación de objeto sin nombre
Actividad 1. Representación de clases y objetos con UML
Con el fin de reflexionar sobre la asignatura, en el foro: Cómo representar clases y
objetos con UML construirás 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 compañeros.
1. Recupera lo sustancial de las lecturas del tema 4.1. Representación de objetos y
clases con UML.
2. Identifica la forma más óptima para representar diferentes objetos dados por tu
Facilitador(a).
3. Ingresa al foro y genera una nueva entrada.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 79
4.2. Diagramas y documentación para el diseño del software con UML
Los diagramas se utilizan para representar diferentes perspectivas de un sistema, de
forma que un diagrama es una proyección del propio sistema
El diseño de modelado UML proporciona un amplio conjunto de diagramas que
normalmente se usan en pequeños subconjuntos para poder representar las vistas
principales de la arquitectura de un sistema.
Los seis diagramas de UML que más se utilizan son:
1. Diagrama de caso de uso: describe cómo se usa el sistema; es ideal para comenzar.
2. Escenario de caso de uso (aunque técnicamente no es un diagrama), es una
descripción 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 gráfico de estado, muestra las transiciones de estado. Cada clase podría
crear un diagrama de gráfico de estado.
La siguiente figura muestra cómo se relacionan:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 80
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 relación entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interacción externa.
El caso de uso es la descripción de las secuencias de acciones recíprocas entre dos o
más objetos que se producen entre un actor y el sistema, cuando el actor usa el sistema
para llevar a cabo una tarea específica. 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 específica 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.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 81
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 cómo 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 interactúan 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 ejecución 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 símbolos de caso de uso, y además las
líneas de conexión. Los actores se refieren a una situación de un usuario del sistema, por
ejemplo un actor podría ser cliente.
Los actores dan o reciben los datos del sistema. Los actores secundarios ayudan a
mantener el sistema en ejecución o proporcionan ayuda, como las personas que operan
el centro de atención telefónica, los empleados(as) de ventanilla, etcétera.
Un caso de uso ilustra a los desarrolladores un panorama de lo que quieren los usuarios.
No tiene detalles técnicos o de implementación.
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 desempeña las acciones
activadas por el evento.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 82
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 básicos:
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 podría ser una lista parcial que se extiende en las últimas fases
del análisis. 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.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 83
Figura 4.4. Ejemplo de caso de uso de matriculación de estudiante (Kendall & Kendall,
2005: 669)
La figura muestra un caso de uso de una matriculación 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
podría ser parte de un sistema para matricular a los estudiantes de un curso en línea.
Pareciera como si el caso de uso Cambiar información del estudiante fuera una
característica menor del sistema y no se debiera incluir en el diagrama de caso de uso,
pero debido a que esta información cambia con frecuencia, la administración tiene un
interés sutil en permitir a los estudiantes cambiar su propia información personal. El hecho
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 84
de que los administradores juzguen esto como importante no solo justifica, sino que exige
que el estudiante pueda cambiar su información.
A los estudiantes no se les permitiría cambiar su promedio de calificaciones, cuotas a
pagar y otra información. Este caso de uso también incluye el caso de uso Verificar
identidad, y en esta situación, significa que el estudiante tiene que introducir una clave de
usuario y contraseña antes de acceder al sistema. Ver información del estudiante permite
a los estudiantes visualizar su información personal, así como también los cursos y
calificaciones.
Los diagramas de caso de uso son un buen punto de partida, pero se necesita una
descripción más completa de ellos para su documentación.
Figura 4.5. Cuatro tipos de relaciones (Kendall & Kendall, 2005: 667)
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 85
4.2.2. Escenarios del caso de uso
Cada caso de uso tiene una descripción 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 desempeñados.
3. Condiciones, suposiciones y preguntas.
Este podría ser el caso de uso (use case) de escribir un mensaje en un foro.
Nombre: Crear mensaje foro
Autor: Juan Pérez
Fecha: 28/03/2011
Descripción:
Permite crear un mensaje en el foro de discusión.
Actores:
Usuario de Internet firmado.
Precondiciones:
El usuario debe haberse firmado en el sistema.
Flujo Normal:
1. El actor pulsa sobre el botón para crear un nuevo mensaje.
2. El sistema muestra una caja de texto para introducir el título del mensaje y una
zona de mayor tamaño para introducir el cuerpo del mensaje.
3. El actor introduce el título 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 permitiéndole que los corrija.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 86
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 dinámica
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 acción, que está compuesta de ejecutables que producen un cambio en
el estado del sistema o la devolución de un valor. Las acciones incluyen llamadas a otras
operaciones, envío de señales, creación o destrucción de objetos, o simples cálculos
(como la evaluación de una expresión).
Gráficamente, un diagrama de actividades es una colección de nodos y arcos.
Básicamente un diagrama de actividades contiene:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 87
Estados de actividad. La representación de este estado está basada en un
rectángulo con las puntas redondeadas, donde el interior se representa una
actividad. El estado de actividad puede descomponerse en más sub-actividades
representadas a través 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.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 88
Figura 4.7 Diagrama de actividades para modelar una actividad (Alarcón, 2005: 73)
Estados de acción. Al igual que el estado de actividad, el estado de acción, está
basado en un rectángulo con las puntas redondeadas, donde en el interior se
representa una acción.
Transiciones. Las transiciones muestran el paso de un estado a otro, bien sea
estado de actividad o de acción. Esta transición se produce como resultado de la
finalización del estado del que parte el arco dirigido que marca la transición. Como
todo flujo de control debe empezar y terminar en algún momento, se puede indicar
esto utilizando dos disparadores de inicio y final.
Figura 4.8.Transición
4.2.4. Diagrama secuencial
Los diagramas de secuencia son un tipo de diagramas nombrados de interacción, y
constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se
pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas
de secuencia enfatizan el ordenamiento temporal de los mensajes, mientras que los
diagramas de colaboración muestran la organización estructural de los objetos que envían
y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de
colaboración sin pérdida de información, lo mismo ocurre en sentido opuesto.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 89
Figura 4.9. Representación de clases en diagramas de secuencia
Un diagrama de secuencia en el modelado UML muestra una interacción ordenada según
la secuencia de cada evento. Muestra los objetos participantes en la interacción y los
mensajes que intercambian, ordenados según 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 interacción, sin un orden prefijado. Cada objeto o actor tiene una línea 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,
métodos y visibilidad, y relaciones: herencia, composición, agregación, asociación y uso.
Elementos
Clase
Es la unidad básica que incluye toda la información de un Objeto, y un objeto es una
instancia de una clase. A través de ella podemos modelar el entorno en estudio: una
Casa, un Auto, una Cuenta Corriente, etc.
En UML una clase es representada por un rectángulo que posee tres divisiones:
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 90
Figura 4.10.Representación 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 métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o
public).
Un ejemplo sobre el diagrama de clase:
Un Crédito que posee como característica:
Solicitud
Puede realizar las operaciones de:
Investigación de Crédito (investigación)
Análisis de crédito (análisis)
Y Entrega de crédito (entrega)
El diseño asociado es:
Figura 4.11. Representación de la clase cuenta
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 91
Atributos y Métodos:
Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el
grado de comunicación 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 sólo será accesible desde dentro de la clase (sólo
sus métodos lo pueden accesar).
protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero
si podrá ser accesado por métodos de la clase además de las subclases que se deriven
(ver herencia).
Métodos:
Los métodos u operaciones de una clase son la forma en cómo ésta interactúa con su
entorno, éstos pueden tener las características:
public (+, ): Indica que el método será visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.
private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo
otros métodos de la clase lo pueden accesar).
protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero
sí podrá ser accesado por métodos de la clase además de métodos de las subclases que
se deriven (ver herencia).
Actividad 2. Aplicación de diagramas
Esta actividad tiene como finalidad aplicar cada uno de los conceptos básicos 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 definición
y en qué utilizarías cada uno de ellos de acuerdo al concepto entendido.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 92
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. Envía el archivo a tu Facilitador(a) a través de Tareas.
4.2.6. Diagrama de gráfico 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 cuáles son las respuestas y acciones que da por resultado.
Un diagrama de estados es un gráfico 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 transición 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 acción de entrada aparece en la forma entrada/acción_asociada donde
acción_asociada es el nombre de la acción que se realiza al entrar en ese estado, cada
vez que se entra al estado por medio de una transición, la acción de entrada se ejecuta.
Una acción de salida aparece en la forma salida/acción_asociada, cada vez que se sale
del estado por una transición de salida la acción de salida se ejecuta. Una acción interna
es una acción que se ejecuta cuando se recibe un determinado evento en ese estado,
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 93
pero que no causa una transición a otro estado. Se indica en la forma
nombre_de_evento/acción_asociada.
Figura 4.12. Gráfico de estado de conexión a Internet
Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la
que hay un estado inicial de creación y un estado final de destrucción (finalización del
caso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólido
y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados
inicial y final no son estados, pues un objeto no puede “estar” en esos estados, pero nos
sirven para saber cuáles son las transiciones inicial(es) y final(es).
Actividad 3. Diseño de diagramas en UML
Esta actividad tiene como finalidad aplicar cada uno de los conceptos básicos delos
diagramas casos de uso, actividades secuenciales, clase y gráfico de estado.
1. En Word o Microsoft Visio diseña un ejercicio para cada uno de los diagramas,
suponiendo que se quiere diseñar un sistema para el control de ventas de una farmacia
en donde el usuario sería el despachador de la misma.
2. Describe cada uno de los diagramas y su contenido o justificación.
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.
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 94
4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.
Autoevaluación
Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
unidad del curso, es necesario que resuelvas la actividad integradora. Recuerda que es
muy importante leer cuidadosamente los planteamientos indicados y elegir la opción
adecuada para cada uno.
Evidencia de aprendizaje. Diagramas UML
Como parte de la evaluación de esta unidad, realiza la siguiente actividad cuyo propósito
es conceptualizar el proceso de diagramación.
Instrucciones:
1. En un archivo de texto o Microsoft Visio diseña un ejercicio para cada uno de los
diagramas que revisaste en esta unidad, señalando el o los usuarios.
2. Describe cada uno de los diagramas y su contenido o justificación.
3. Consulta la Escala de evaluación.
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. Envía el archivo a tu Facilitador(a) a través de Evidencia de aprendizaje, para recibir
retroalimentación.
Autorreflexiones
Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a)
presente; a partir de ellas debes elaborar tu Autorreflexión en un archivo de texto llamado
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 95
DOO_U4_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta
Autorreflexiones.
Cierre de la unidad
Has concluido la unidad 4 del curso. A lo largo de ésta se vieron conceptos de diseño
orientado a objetos con UML, cómo se representan los objetos y las clases, además de
cómo se hacen los diagramas para los casos de uso, escenarios del caso de uso,
diagramas de actividades, diagramas secuenciales, de clase y el gráfico de estado.
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 éste tu caso, ya
habrás terminado tu curso de Análisis y diseño Orientado a Objetos, ¡FELICIDADES!
Para saber más
Insertar o crear un dibujo de Visio en otro programa:
Cómo 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
Alarcón, Raúl. (2005). Diseño orientado a objetos con UML. Grupo Eidos. Página
73.
Fowler, M. & Scott, K. (1999) UML GOTA A GOTA México: 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
Análisis y diseño orientado a objetos Programa desarrollado
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 96
Kendall, J. & Kendall, J. (1990) Análisis y Diseño de sistemas. México: Prentice
Hall Iberoamericana.
Larman, C. (2004) Applying UML and Patterns an Introduction to object-Oriented
Analysis and Design. México: Prentice Hall.
Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML
México: Addison Wesley.