UNIVERSIDAD DE PANAMÁ

CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS

FACULTAD DE INFORMÁTICA, ELECTRÓNICA Y COMUNICACIÓN
LICENCIATURA EN INFORMÁTICA PARA LA GESTIÓN EDUCATIVA Y

PROGRAMACIÓN IV

Proyecto #1
PRIMERA ETAPA
ANÁLISIS OO

ESTUDIANTES

Isis Reyes 2-160-330

Luz María Dutari 9-717-
1496

Profesor
Diego Santimateo

2006
 INDICE

Págs
.
Introducción 2
Objetivos 3
- Objetivo General del proyecto 3
- Objetivos Específicos 3
A-ORGANIZACIÓN Y RESULTADO DE ENTREVISTA 4
B- UTILIDAD DE LA INFORMACIÓN 7
I.- DESCRIPCIÓN DEL PROBLEMA O DOMINIO 8
1.1-Definición del dominio 8
1.2- Objetivos del sistema 8
1.2.1- Objetivo general 8
1.2.2- Objetivo específicos 8
1.3- Lista de requisitos del sistema 8
II- ANÁLISIS ORIENTADO A OBJETOS DEL SISTEMA 9
2.1- Identificación de las clases 9
2.1.1- Descripción de las clases del sistema 9
2.2- Glosario de términos 11
2.3- Identificación de las relaciones entre clases 11
2.3.1- Diagrama de relación de clases 11
2.4- Identificación de atributos o propiedades de las clases 12
2.4.1- Diagrama UML de clases, atributos y métodos. 13
2.5- Diagrama de casos de uso del sistema 15
- Caso de uso: Control de calificaciones 15
- Caso de uso: Determinar desempeño docente 16
- Caso de uso: Determinar eficiencias y estadísticas por salón 16
2.6- Reflexiones Finales 17
Webgrafías / bibliografías 19
Anexos 20

2
 INTRODUCCIÓN

En este trabajo de Programación IV, se presentan la primera etapa de

la Programación Orientada a Objetos, la cual es el Análisis Orientado a
Objetos, en la que se detalla cada uno de los pasos que conlleva la misma.
Esta se realizó a través de una investigación en una escuela secundaria de la
ciudad de Santiago, provincia de Veraguas, en este caso el C.E.B.G Belisario
Villar Pérez, el mismo trata de una propuesta UML de un modelo Orientado a
Objetos de un sistema de administración escolar específicamente del
desempeño académico.

El mismo es presentado a través de su fases de análisis, resolución del

problema como su respectivas objetivos detallados en la continuidad de este
trabajo.

Se presenta los pasos o etapas del análisis orientado objetos, como los
diagramas UML necesarios para la comprensión y desarrollo del sistema y
metodología utilizada para poder llevar a cabo este proyecto.

Al final de esta primera etapa o informe se presentan un resumen

detallado de los diagramas UML fundamentales para el desarrollo del
sistema.

Se señalan las reflexiones finales de cada estudiante en la elaboración

del informe, como sus conocimientos en el proyecto y debilidades en su
realización.

3
OBJETIVOS

- Objetivo General del proyecto

o Realizar un análisis basado en el enfoque de orientación de objetos de un

sistema de administración escolar de secundaria.

- Objetivos Específicos

o Desarrollar las distintas etapas que conforman el análisis orientado

a objetos.
o Diseñar modelos UML del dominio del problema basado en la
metodología de desarrollo de sistemas (POO).

4
 - A- ORGANIZACIÓN Y RESULTADOS DE ENTREVISTA

Para realizar esta primera etapa (análisis OO) de este proyecto de la

Programación Orientada Objetos, la cual tiene el objetivo de una propuesta
UML del funcionamiento de un sistema de administración escolar de
secundaria enfocado al desempeño académico, escogimos para ello, el
Centro de Educación Básica General Belisario Villar Pérez ubicado en Canto
del Llano – Barriada Las América.

En el mismo se realizó las entrevistas pertinentes a las personas

encargadas de realizar este funcionamiento.

Preguntas efectuadas:
1.-¿Quienes son las personas encargadas de llevar los
procesos de administración escolar, en cuanto al desempeño
académico?
- Control de calificaciones - Administración

- Deficiencias - Administración
- Estadísticas por salón - Administración
- Puesto de Honor - Departamento de matemática.
- Eficiencia docente - Supervisor

2.- ¿Cómo realizan el proceso de control de calificaciones?

- Cada profesor presenta un resumen escolar de las calificaciones
bimestrales por asignatura. La misma debe contener:
- Primer ciclo, estudiantes matriculados, aprobados en el
bimestre con (total y porcentaje), estudiantes reprobados (total
y porcentaje), reprobados hasta la fecha, estudiantes sin nota
(total y porcentaje).

5
3.- ¿Cómo son detectadas las áreas de deficiencia?
- Las áreas son detectadas por asignaturas la cual son detalladas
en un cuadro por el departamento de estadísticas, la misma
contiene:
- Total de Asignaturas, el total de matriculados en cada
materia, cantidad de estudiantes con deficiencia en la
misma, porcentaje,.

Cabe resaltar que este cuadro se hace por grupo y por bimestre hasta
el Noveno grado.

4.- ¿Cómo se realizan las estadísticas por salón?

- Las estadísticas se realizan a través de un informe por semestre
que presenta el profesor coordinador de grupo, el mismo
muestra los siguientes datos:
- Año, estudiantes reprobados, estudiantes aprobados,
fracasos hasta la fecha, estudiantes sin calificación y
estudiantes retirados.

5.- ¿Cómo es calculado los estudiantes de puesto de honor?

- Los estudiantes de puesto de honor son calculados por un
grupo de profesores del área de matemáticas que llevan un
control de todas las notas finales de cada estudiante desde
que están en el séptimo grado hasta el noveno grado, el
mismo se calcula sumando el total de las notas obtenidas en
cada año académico entre la cantidad que es la suma de
todas las materias que tomo el séptimo grado hasta el
noveno grado, este con el objetivo de no dejar escapar
decimales que son muy importantes para conocer el primer,
segundo y tercer puesto de honor.

6
7
6.- ¿Se realiza una evaluación docente que muestre el
desempeño del mismo?
- Si, se realiza una evaluación docente, efectuada por un
supervisor, la cual el docente es avisado con anterioridad del
mismo. Esta evaluación realizada en un acta de visita de
observaciones de la clase, que lleva a cabo el supevisor
encargado, basado en ítem observables, la cual es llenada
de acuerdo a la que se observa de la labor administrativa y
la labor técnica de mismo. Se utiliza una escala de puntaje
100-91=E=5 (equivalencia); 90-81=Bueno=B=4; 80-
71=Regular=R=3; 70- menos=Deficiente=D=2. El acta
recaba información como: nombre del docente a evaluar,
especialidad, grado que atiende, horario, fecha de visita,
jornada, matricula, asistencia.

Estas fueron las preguntas efectuadas a los docentes encargados a

cada una de las requisitos necesarios para el análisis del proyecto.

8
B- UTILIDAD DE LA INFORMACIÓN

Es importante todos estos datos recabados de la entrevistas realizadas

a las personas responsables de llevar a cabo los procesos a mención, para
poder realizar un análisis detallado de un sistema de administración escolar
y confeccionar los respectivos diagramas UML que esta primera etapa
requiere (análisis OO).

Por tanto es de gran utilidad, conocer los requisitos necesarios que

debe cumplir un sistema para satisfacer las necesidades de los usuarios,
reflejando así que debe hacer el sistema, y poder realizar un análisis OO, con
sus respectivos diagramas UML que muestran como debe realizarse el
sistema para luego detallar su diseño OO.

9
I.- DESCRIPCIÓN DEL PROBLEMA O DOMINIO

En el centro de educación básica general Belisario Villar se necesita un

sistema informático en el área de administración escolar que gestione todo
lo relacionado al desempeño académico tanto de alumnos como docentes
que lleve el control de las calificaciones, identifique las áreas de deficiencias
y las estadísticas por salón, puestos de honor, y evalúe la eficiencia de los
docentes.

1.1-Definición del dominio

El dominio de el sistema de acuerdo a la abstracción del problema se
enfoca a la escuela, ya que dentro de ella se lleva acabo la administración
escolar, especialmente el desempeño académico, la cual trata este
proyecto.

1.2-Objetivos del Sistema

1.2.1-Objetivo general
• elaborar un sistema informático que gestione las operaciones
relacionadas al desempeño académico como uno de los procesos que
conforman la administración escolar.

1.2.2 - Objetivos Específicos:

• Llevar el control de las calificaciones de un año, un bimestre o historial.
• Identificar áreas en las que los estudiantes pueden presentar
deficiencias y mostrar las estadísticas por salón.
• Calcular las notas de los estudiantes para determinar los puestos
honor.
• Determinar el desempeño docente de la labor administrativa y técnica
del mismo.

10
1.3- Lista de Requisitos del Sistema
Esta lista muestra los requisitos que el sistema debe cumplir:
1. Llevar a cabo un control de calificaciones de los estudiantes durante el
bimestre y el año.
2. Mostrar una estadística de las áreas de deficiencia por salón.
3. El sistema permitirá calcular los puestos de honor tomando en cuenta las
notas y materias dadas en los tres niveles (7º, 8º, 9º).
4. Mostrar el desempeño docente a través de una escala de valorización.
II- ANÁLISIS ORIENTADO A OBJETOS DEL SISTEMA

2..1- Identificación de las clases

Después de describir el problema para ello utilizaremos una de las

técnicas descritas en el documento de Miguel Ángel Abián sobre POO en
donde utilizaremos la técnica de identificación de sustantivos que aparecen
en la descripción del problema.

Clases del Dominio

Estudiante
Calificaciones
Profesor Asignatura

PuestoHonor CapturaDespliega

2.1.1- Descripción de las clases del sistema

Luego de haber obtenido los requisitos del sistema proporcionada por

los que realizan el proceso de desempeño escolar los docentes y

11
administración, y de haber abstraído las clases que formaran parte de
nuestra propuesta de un sistema Orientado a objeto, describimos cada clase
obtenida, como los atributos y operaciones que cada una de ella cumplirá en
el sistema.

A continuación descripción detallado del funcionamiento del sistema:

12
 Descripción del Funcionamiento de cada Clase
Clases Objetivo
Estudiante Esta clase contiene los datos personales del
estudiante con sus calificaciones y determina
el desempeño académico del mismo
tomando en cuenta sus calificaciones.
Docente Contiene los datos del profesor y la cátedra
que enseña, determina el desempeño del
docente de acuerdo a una escala establecida
como excelente, buena y regular.
Asignatura Registra las asignaturas, el nivel, cantidad de
estudiantes matriculados y las calificaciones
para calcular la cantidad de estudiantes
aprobados y reprobados para luego
determinar si en la asignatura existen
deficiencias.
Calificaciones Esta clase contiene las propiedades
necesarias que son: las calificaciones,
nombre del estudiante, grados (atributos),
estas caracteristicas de clase son
importantes, para poder obtener el promedio
bimestral y final del estudiante, para ello se
utrilizará los métodos PromedioBimestral(),
estos métodos calculará el promedio
bimestral de las calificaciones obtenidas en
cada asignatura entre las cantidad de
materias que son tomadas en el mismo, por
otro lado para obtener el promedio final se
utilizará el metodo PromedioFinal(), que
calculará el promedio que llevara el
estudiante en el año,obtenida de la suma de
los promedios bimestrales entre la suma total
de las materias dictadas en los bimestres,
para esto se necesitará de los atributos de
calificaciones del estudiante por bimestre, los
grados, y su respectivo nombre. Esta clase
contendra todos estos elementos que estará
relacionada con la clase PuestoHonor y Clase
Asignatura.

PuestoHonor Esta clase define un conjunto de propiedades

y atributos que tiene la función de
determinar los puestos de honor, la cual se
obtiene tomando en cuenta las
calificaciones, nombre del estudiante y las
cantidad de materias que el estudiante a
recopilado en el séptimo, octavo y noveno
grado (atributos de la clase), y la
implementación de una operación de esta
clase es MayorPromedio(), esta operación
se encarga de obtener el estudiante que
tiene el mayor promedio con relación a un
grupo de estudiantes y obtener el estudiante
de primer puesto de honor, es por ello 13 que
necesita los atributos de calificaciones.
CapturaDespliega Esta clase será utilizadas para capturar los
 2.2 - Glosario de Términos
Como los términos relacionados al dominio del problema son de uso
común se omitirá esta etapa y pasaremos a la siguiente etapa.

2.3- Identificación de las Relaciones entre las clases

• Los estudiantes tienen asignaturas.
• Los estudiantes tienen profesores.
• El puesto de honor se calcula a partir de las calificaciones del
estudiante.
• Los docentes entregan las calificaciones de los estudiantes a la
administración del plantel.
• Los docentes calculan el puesto de honor.
• Las calificaciones determinan el desempeño de los estudiantes en las
asignaturas.

2.3.1- Diagrama de relaciones de las clases

Class Asignaturas
entrega NombreAsig;
Class Docente n Matricula;
Class Estudiante Nombre; Grado;
Nombre; Codigo;
Calificaciones; Asignatura;
Grado; Desempeño;
Grados;
calcula

Calculan
tienen promedio

Class
PuestosdeHonor
Nombre_est;
Class Calificaciones;
Calificaciones Determina Cant_materias;
Nombre_est; n
Notas_bimestrales desempeñ
;

14
2.4 Identificación de los atributos y propiedades de las clases
En esta etapa procedemos a identificar los atributos y propiedades que
tendrán las clases que conforman el sistema a través de un diagrama de
Modelamiento de clases para una mejor visualización de atributos y
propiedades de las mismas.

A continuación diagrama UML de las clases

15
 2.4.1- Diagrama UML de clases, atributos y métodos.

Class
DesempeñoAcadem
ico
Class
CapturaDespliega

Capturar();
Despliega();
Ordenar();

Main();

Class Class Docente Class Class Class

Estudiante Asignatura PuestoHonor Calificaciones
Nombre;
Nombre; Codigo;
Calificaciones; Grado; NombreAsig; Nombre_est; Nombre_est;
Grado; Asignatura; Grado; Calificaciones; Notas_bimestral
Matricula; Cant_materias; es;
CalcularDesempe EficDocente(); Calificaciones; grado;

MayorPromedio(); PromedioBimest
Reprobados();
MatDef();

16
 2.5- Diagrama de casos de usos del sistema
En todo análisis OO, es necesario diseñar diagramas de usos que nos
ayudan a desarrollar y visualizar un sistema , estos diagramas son los
siguientes:

Caso de uso: Control de Calificaciones

Nota
Semestral

<<extends>> <<uses>> Genera

Lleva
control de calificación

Desempeño /
promedio

Entrega
calificación <<uses>>

Docente Nota Final

<<extends>>

Estudiante

Genera historial
académico

17
 Caso de uso: Determinar desempeño docente
<<extends>>
Labor
Técnica
Genera

<<uses>> <<extends>>
Labor
Obtiene
administrativa
evaluación

Evalúa
desempeñ
Evaluador
Docente
<<uses>>

Determina
eficiencia

Caso de Uso: Obtener deficiencias y estadisticas por salón

Genera
calificaciones

<<uses>>
Obtiene
calificaciones

<<uses>>

Calcula y
Docentes obtiene Grupo
Estudiantes
<<uses>> <<uses>>

Determina
Obtiene
eficiencia por
estadísticas por
asignatura
salón

18
2.6- Reflexiones finales

El grupo esta conformado por dos estudiantes: Isis Reyes y Luz María
Dutari, el grupo ha trabajado arduamente en esta primera etapa, en la cual
ha consultado todas las fuentes de información suministradas por el profesor
asesor , además de otras fuentes primarias relacionadas con el análisis
Orientado Objeto y a al diseño de diagramas UML.

Cabe resaltar que se ha hecho un análisis exhaustivo a lo requerido en

esta primera etapa, en la que esperamos haber realizado un análisis
bastante detallado de lo que se requiere para la segunda etapa que es
Diseño Orientado a Objetos.

Después de haber comentado en cuento a los puntos más difíciles de

esta etapa, hemos llegado a la conclusión el punto un poco complicado fue la
confección de diagramas UML, ya que el mismo son de acuerdo a su uso, a lo
que se desea que haga el sistema sin entrar en detalles del cómo.

- La metodología utilizada:
Detallamos como manera más detallada de la metodología utilizada
para el logro de los objetivos de esta primera etapa de la POO.
1- Estudio y análisis del documento pdf de Miguel Ángel Abian, en cuanto
a Análisis OO.
2- Desarrollo de marco Conceptual de la etapa de Análisis Orientado a
Objetos.
3- Resumen de los recursos ofrecidos por el docente (Tutorial UML).
4- Organización de las preguntas a realizar en el Centro Educativo.
5- Entrevista a los docentes y administrativos de la escuela C.E.G.
Belisario Villar Pérez, la cual son los expertos del dominio de la
Administración Escolar.

19
6- Recolección de los datos o resultados de la entrevista realizada.
7- Análisis de los datos o requisitos obtenidos.
8- Abstracción del dominio del problema.
9- Desarrollo de cada etapa de Análisis Orientado Objetos.
10-Desarrollo de análisis de diagramas UML del sistema.

- Conocimientos adquiridos:

Isis: Obtuve buenos conocimientos en cuanto a un análisis OO,

detallando cada una de las etapas y ponerlas en práctica, logre
profundizar una parte en los diagramas UML y digo una parte, ya que
después de investigar y leer en Internet, pude darme cuenta que existen
muchos diagramas UML que ayudan al programador tener una mejor
comprensión y diseño del mismo, y que estos diagramas van a depender
del sistema que se desea elaborar.

Por consiguiente, he comprendido que para entrar antes a programar

un sistema es necesario reconocer el problema o dominio del mismo, y
que ha medida que se va desarrollando los pasos de manera ordenada,
nos damos cuentas de que clases estas involucradas o necesarias en el
sistema, y que éstos se logra siguiendo las etapas de la metodología de
desarrollo de sistemas (OO).

La importancia de realizar estos tipos de trabajo es obvia, ya que a

través de una buena planificación, desarrollo, metodología adecuada de
estudio y análisis se puede obtener buenos resultados en futuros trabajos
y proyectos profesionales, convirtiéndome en una persona productiva.

20
 Luz María: La programación orientada a objetos (POO) es una
metodología de desarrollo de software para analizar y estudiar cualquier
sistema desde un enfoque del conocimiento del mundo real.
Considero que al estudiar un sistema con esta metodología se hace más fácil
su análisis, diseño e implementación ya que asociamos los conceptos con
objetos del mundo con los que estamos más relacionados.

21
 BIBLIGRAFÍAS/WEBGRAFIAS

- Documento pdf. Miguel Angel Abian. Análisis OO.

o http://www.javahispano.org/tutorials.item.action?id=25

- Herramienta para diseño de mapa conceptual

o http://cmap.ihmc.us/

- Tutorial UML

o http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html

22
23
 RESUMEN-INDIVIDUAL-ISIS REYES

TUTORIAL DE UML

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language)

es un lenguaje gráfico para visualizar, especificar y documentar cada una de
las partes que comprende el desarrollo de software.

Se representa 3 diagramas que son:

- Modelamiento de las clases

- Caso de Uso
- Diagrama de Interacción

MODELAMIENTO DE LAS CLASES

Un diagrama de clases sirve para visualizar las relaciones entre las clases
que involucran el sistema, las cuales pueden ser asociativas, de herencia, de
uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Elementos Descripción Representación

24
Clases : Es la unidad básica que
atributos, encapsula toda la información de
métodos, un Objeto (un objeto es una
visibilidad instancia de una clase). A través
de ella podemos modelar el
entorno en estudio.En UML, una
clase es representada por un
rectángulo que posee tres
divisiones.
Superior: Contiene el nombre
de la Clase.Intermedio:
Contiene los atributos (o
variables de instancia) Inferior:
Contiene los métodos u
operaciones(dependiendo de la
visibilidad: private, protected o
public).
- Atributos: pueden ser de
tres tipos, los que definen el
grado de comunicación y
visibilidad de ellos con el
entorno, estos son: public,
private, protect.
- Métodos: son la forma en
como ésta interactúa con su
entorno, éstos pueden tener
las características:
public, private, protected.
En UML, la cardinalidad de las
relaciones indica el grado y
nivel de dependencia, se
Relaciones: anotan en cada extremo de la
herencia, relación y éstas pueden ser:
composición,
agregación, - uno o muchos: 1..*
uso, asociación. (1..n)
- 0 o muchos: 0..* (0..n)
- número fijo: m (m
denota el número).

- Herencia: Indica que una

subclase hereda los métodos
y atributos especificados por
una Super Clase, por ende la
Subclase además de poseer
sus propios métodos y
atributos, poseerá las

25
 características y atributos
visibles de la Super Clase
(public y protected).

- Agregación: Para modelar

objetos complejos, n bastan
los tipos de datos básicos que
proveen los lenguajes:
enteros, reales y secuencias
de caracteres. 2
posibilidades: por valor, por
referencia.

- Asociación: permite asociar

objetos que colaboran entre
si. Cabe destacar que no es
una relación fuerte, es decir,
el tiempo de vida de un objeto
no depende del otro.

- Dependencia: Representa
un tipo de relación muy
particular, en la que una clase
es instanciada (su
instanciación es dependiente
de otro objeto/clase).
- Casos - Abstracta: Una clase
particulares abstracta se denota con el
nombre de la clase y de los
métodos con letra "itálica".
Esto indica que la clase
definida no puede ser
instanciada pues posee
métodos abstractos (aún no
han sido definidos, es decir,
sin implementación). La única
forma de utilizarla es
definiendo subclases, que
implementan los métodos
abstractos definidos.

- Clase parametrizada: se
denota con un subcuadro en
el extremo superior de la
clase, en donde se especifican

26
los parámetros que deben ser
pasados a la clase para que
esta pueda ser instanciada.

27
 CASOS DE USO

El mismo representa como un cliente (actor) opera con el sistema en

desarrollo, como la forma, tipo y orden en como interactúan sus elementos
(operaciones).

Los elementos de diagrama de casos, lo presentamos en el siguiente cuadro:

Element Descripción Representación

os
Actor es un rol que un usuario juega con respecto al sistema.
No necesariamente representa a una persona en particular,
sino más bien la labor que realiza frente al sistema.
Es una operación/tarea específica que se realiza tras una orden
Caso de de algún agente externo, sea desde una petición de un actor o
Uso bien desde la invocación desde otro caso de uso.
Las relaciones se representa por
- Asociaciones Idica la invocación desde un actor o caso de
uso a otra operación (caso de uso). Denotada
con flecha simple.
Relacione Cumple una doble función dependiendo de su
s estereotipo, que puede ser de Uso
- (<<uses>>) o de Herencia (<<extends>>).
Generalizacione - extends: Se recomienda utilizar
s cuando un caso de uso es similar a
otro (características).
- uses: Se recomienda utilizar cuando
se tiene un conjunto de
características que son similares en
más de un caso de uso y no se
desea mantener copiada la
descripción de la característica.
-Dependencia o Es una forma muy particular de relación
Instanciación entre clases, en la cual una clase
depende de otra. Se crea.

Entonces, el diseño completo del diagrama Use Case es:

28
 DIAGRAMA DE INTERACCIÓN

El diagrama de interacción, representa la forma en como un Cliente

(Actor) u Objetos (Clases) se comunican entre si en petición a un evento.
Este se puede obtener desde el Diagrama Estático de Clases o el de Casos
de Uso (son diferentes).

Los componentes de un diagrama de interacción son:

Elementos Descripción Representación

Objeto/actor El rectángulo representa
una instancia de un
Objeto en particular, y la
línea punteada
representa las llamadas
a métodos del objeto.
Mensaje a otro actor Se representa por una
flecha entre un objeto y
otro, representa la
llamada de un método
(operación) de un objeto
en particular.
Mensaje al mismo objeto No solo llamadas a
métodos de objetos
externos pueden
realizarse, también es
posible visualizar
llamadas a métodos
desde el mismo objeto
en estudio.

Ejemplo: Modelo estático.

29
30
 RESUMEN-INDIVIDUAL-LUZ MARIA DUTARI

Diagramas UML:

Casos de Uso:
El diagrama de casos de uso representa la forma en como un usuario trabaja
con el sistema en mención para lograr los resultados esperados y también la
forma, tipo y orden en como los elementos del sistema interactúan entre sí
(operaciones o casos de uso).

Elementos de un diagrama de casos de uso:

- Actor: un actor es un papel (rol) que un usuario juega con respecto al

sistema. Es importante destacar el uso de la palabra rol, pues con esto
queremos decir que un actor no es el que va a representar a una
persona, sino más bien al trabajo o labor que realiza en el sistema
estudiado.
- Caso de uso: es una operación o procedimiento que se realiza como
respuesta a una orden ya sea de un actor o desde la invocación de otro
caso de uso.
- Relaciones:
• Asociación: dentro del análisis de un sistema es el tipo de
relación más básica que existe e indica el llamado desde
un caso de uso a otra operación (caso de uso). Se denota con
una flecha simple.
• Dependencia o Instanciación: a partir de una clase se pueden
crear otras clases de tipo objetos o instancias lo que de lugar a
una relación entre ellas de dependencia o instanciación (una
depende de la otra).
• Generalización: este tipo de relación es uno de los más utilizados
y cumple una doble función dependiendo del paradigma, que
puede ser de uso (uses) o de herencia (extends). Extendí se
utiliza cuando un caso de uso es similar a otro en sus
características, mientras que el uses se utiliza cuando existen
características similares en más de un caso de uso.

Diagrama de Interacción:

El diagrama de interacción, representa la forma en como se relacionan entre

sí las clases y los objetos dentro de su dominio frente al llamado de una
operación o tarea.

Elementos de una diagrama de Interacción:

31
 - Objeto/Actor: en el diagrama el rectángulo representa un objeto en
particular, y la línea punteada las llamadas a métodos del objeto.
- Mensaje a otro objeto: es el llamado de un método de un objeto en
particular y se representa por una flecha entre un objeto y otro.
- Mensaje al mismo objeto: hasta el momento hemos visto el llamado
a métodos de objetos externos pero también es posible realizar
llamadas a métodos pertenecientes al mismo objeto en estudio.

Modelo de clases:

Un diagrama de clases representa las relaciones que existen entre las clases
que interactúan en el sistema y pueden ser asociativas, de herencia, de uso
y de contenimieto.

Elementos de un diagrama de clases:

- Clase: una clase es un modelo por el cual podemos representar todas las
características relevantes de un objeto ya que un objeto es una instancia de
una clase.
En UML, una clase es representada por un rectángulo que posee tres
divisiones:
• Superior: contiene el nombre de la clase.
• Intermedio: contiene los atributos que caracterizan a la clase.
• Inferior: contiene los métodos, los cuales son la forma como interactúa
el objeto con su entorno.

- Atributos y métodos: los atributos de una clase pueden ser de tres tipos,
según el grado de comunicación y visibilidad de los mismos con el entorno,
estos son:
• public: se puede acceder al atributo tanto dentro como fuera de la clase.
• Private: el atributo sólo será accesible desde dentro de la clase esto
quiere decir que sólo sus métodos lo pueden acceder.
• Protected: indica que no se pude acceder al atributo desde otra clase,
pero si puede ser accesado por métodos de la clase y por las subclases
que de deriven de ella.

- Métodos: los métodos son la forma en como las clases interactúan

con otras clases y objetos dentro de su entorno, los métodos también
pueden presentar características como las mencionados anteriormente
en los atributos.

- Relaciones entre clases: para poder entender bien como se representan

las relaciones entre clases es necesario conocer el concepto de cardinalidad

32
de las relaciones. En UML la cardinalidad de las relaciones indica el grado y
nivel de dependencia entre las clases y éstas pueden ser:
• uno o muchos: 1..*(1..n)
• 0 o muchos:0..*(0..n)
• número fijo:m (m denota el número).

- Herencia (Especialización/Generalización): la herencia nos indica que

una subclase hereda los métodos y atributos especificados por una
superclase, por ende la subclase además de poseer sus propios atributos y
métodos, poseerá las características y atributos visibles de la superclase.

- Agregación: si queremos crear objetos complejos, es suficiente con los

tipos de datos básicos que proveen todos los lenguajes de programación
como enteros, reales y cadena de caracteres.
Pero si lo que queremos es crear objetos que son instancias de una clase
definidas por el programador tenemos dos posibilidades:
• por valor: es un tipo de relación estática en donde la duración de un
objeto está determinada por el tiempo de vida del objeto que lo incluye.
• Por referencia: es un tipo de relación dinámica en donde el objeto base
utiliza al objeto incluido para su funcionamiento.

- Asosiación: este tipo de relación permite asociar objetos que colaboran

entre sí. Esto no indica que el tiempo de vida de un objeto depende de otro.

- Dependencia o Instanciación (uso): denota la dependencia que tiene

una clase de otra para ser instanciada. Se denota por una flecha punteada.

- Casos particulares:
* Clase abstracta: una clase abstracta es aquella que no puede generar
ningún objeto ya que sus métodos son abstractos es decir, no han sido
definidos por lo que no pueden ser implementados y es utilizada solo por
subclases que utilizan los métodos abstractos definidos.
* Clase parametrizada: se denota con un subcuadro en el extremo superior
de la clase, en donde se especifican los parámetros que deben ser pasados a
la clase para que esta pueda ser instanciada.

Lenguaje de Modelamiento Unificado (UML- Unified Modeling

Language): es un lenguaje gráfico para visualizar, especificar y documentar
cada una de las partes que comprende el desarrollo de software. Es una
forma de modelar conceptos como procesos de negocios y funciones de
sistema, además de cosas concretas como escribir clases en un lenguaje
determinado, esquemas de bases de datos y componentes de software
reutilizables. El propósito de este lenguaje es brindar un material de apoyo

33
que le permita a la persona interesada en el tema poder crear sus propios
diagramas y poder entender el modelamiento de diagramas ya existentes.

34
 RESUMEN DE UML- CONCENSO

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling

Language) es un lenguaje gráfico para visualizar, especificar y documentar
cada una de las partes que comprende el desarrollo de software. Este
lenguaje consta de 3 diagramas básico el modelamiento de los sistemas
estos son: Modelamiento de Clases ,Casos de Uso, Diagrama de Interacción ,
cada uno de ellos son explicados a continuación:
- El modelamiento de Clases: Un diagrama de clases sirve para visualizar
las relaciones entre las clases que involucran el sistema, las cuales pueden
ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos: clases

y relaciones.

- clases: Es la unidad básica que encapsula toda la información de un

Objeto, un objeto es una instancia de una clase. Contiene 3 partes:
Nombre de la clase, atributos o variables de instancias, métodos u
operaciones.
o 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, estos son: private: es accesible desde todos
lados, public: sólo será accesible desde dentro de la clase,
protected: 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.

o Métodos: Los métodos u operaciones de una clase son la forma

en como ésta interactúa con su entorno, éstos pueden tener las
características: public, private, protected.

- Relaciones:
o Herencia (Especialización/Generalización): Indica que una
subclase hereda los métodos y atributos especificados por una
Super Clase.
o Agregación: Para modelar objetos complejos, n bastan los tipos
de datos básicos que proveen los lenguajes: enteros, reales y
secuencias de caracteres.
 Por valor: Es un tipo de relación estática.
 Por referencia: Es un tipo de relación dinámica.
o Asociación: La relación entre clases conocida como Asociación,
permite asociar objetos que colaboran entre si.
o Dependencia o Instanciación (uso): Representa un tipo de
relación muy particular, en la que una clase es instanciada (su

35
 instanciación es dependiente de otro objeto/clase). Se denota por
una flecha punteada.

- Diagrama de casos de uso: representa la forma en como un Cliente

(Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden
en como los elementos interactúan.

Un diagrama de casos de uso consta de los siguientes elementos:

• Actor: es un rol que un usuario juega con respecto al sistema.

• Casos de Uso: Es una operación / tarea específica que se realiza tras
una orden de algún agente externo, sea desde una petición de un
actor o bien desde la invocación desde otro caso de uso.
• Relaciones de Uso, Herencia y Comunicación:
o Asociación: indica la invocación desde un actor o caso de uso a
otra operación (caso de uso).
o Dependencia o Instanciación: relación entre clases, en la cual
una clase depende de otra, es decir, se instancia (se crea).
o Generalización:
 extends: Herencia, Se recomienda utilizar cuando un caso
de uso es similar a otro (características).

 uses: Usos, Se recomienda utilizar cuando se tiene un

conjunto de características que son similares en más de un
caso de uso y no se desea mantener copiada la descripción
de la característica.

- Diagrama de interacción: representa la forma en como un Cliente

(Actor) u Objetos (Clases) se comunican entre si en petición a un evento.

Los componentes de un diagrama de interacción son:

• Un Objeto o Actor: representa por un rectángulo, que es una instancia

de un Objeto en particular, y la línea punteada representa las llamadas
a métodos del objeto.
• Mensaje de un objeto a otro objeto: representa la llamada de un
método (operación) de un objeto en particular.
• Mensaje de un objeto a si mismo: es posible visualizar llamadas a
métodos desde el mismo objeto en estudio.

VER MAPA CONCEPTUAL DE ANÁLISIS ORIENTADO A OBJETOS

http://es.geocities.com/analisisoo

36
37