Orientacionobjeto

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
EMPRESARIAL
PROGRAMACIÓN IV
TEMA
DISEÑO Y ANÁLISIS ORIENTADO A OBJETO
FACILITADOR
DIEGO SANTIMATEO
ELABORADO POR
CALLES YORISBETH 9-720-2373
GONZÁLEZ ROMAN 9-705-1420
GONZÁLEZ FÁTIMA 9-721-2074
MANZANÉ ANNETH 9-719-2292
II AÑO
II SEMESTRE
FECHA DE ENTREGA
5 DE OCTUBRE DE 2007
ÍNDICE
Introducción.....................................................................................................1
CONTENIDO.....................................................................................................1
1.ORGANIZACIÓN Y RESULTADOS DE LA ENTREVISTA.....................................1
1.1 Las preguntas efectuadas fueron las siguientes:...................................................................1
2. UTILIDAD DE LA INFORMACIÓN....................................................................3
3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO...................................................3
3.1. Definición del dominio.........................................................................................................4
4. OBJETIVOS DEL SISTEMA..............................................................................4
4.1. Objetivo general....................................................................................................................4
4.2. Objetivos Específicos:..........................................................................................................4
5. LISTA DE REQUISITOS DEL SISTEMA............................................................4
6. ANÁLISIS ORIENTADO A OBJETOS DEL SISTEMA .......................................5
6.1. Identificación de las clases:..................................................................................................5
6.1.1. Clases Involucradas:......................................................................................................5
6.2. Elaboración de Glosario de Términos Procedentes del Dominio:........................................5
6.3. Identificación de las Relaciones entre las clases:.................................................................5
6.4. Diagrama de relaciones de las clases y sus atributos:...........................................................7
6.5. Descripción de las clases del problema................................................................................7
7. IDENTIFICACIÓN DE LOS ATRIBUTOS Y PROPIEDADES DE LAS CLASES......10
7.1 A continuación diagrama UML de las clases.......................................................................11
8. DIAGRAMA DE CASOS DE USOS DEL SISTEMA..........................................12
8.2 Como una primera aproximación identificamos a los actores que interactúan con el
sistema:......................................................................................................................................12
...........................................................................................................................................12
8.3 Caso de uso: Identificación de las áreas de deficiencias.....................................................13
9. COEVALUACIÓN..........................................................................................15
10. REFLEXIONES FINALES.............................................................................18
11. MAPA CONCEPTUAL DE LA FASE DE ANÁLISIS TRATADA EN EL
DODUMENTO DE MIGUEL ÁNGEL ABIÁN........................................................19
WEBGRAFIAS..................................................................................................22
CONCLUSIÓN..................................................................................................23
ANEXO............................................................................................................25
RESUMEN INDIVIDULES..................................................................................26
CONSENSO.....................................................................................................66
INTRODUCCIÓN
Cuando decidimos elaborar el proyecto, iniciamos analizando el

enunciado, estableciendo el objetivo que queremos alcanzar, luego pasamos
a desarrollar los pasos sugeridos del proyecto, que nos permitió desarrollar
un modelo UML de información sobre un sistema de administración escolar
secundario, basado en el enfoque orientado a objeto.
Podemos decir que un sistema de administración escolar de secundaria

enfocado al desempeño académico, que además de llevar a cabo el control
de calificaciones, es capaz de identificar las áreas de deficiencias , las
estadísticas por salón, los puestos de honor y la eficiencia docente.
En la realización de este proyecto hemos elaborado un diseño de

sistema de administración escolar de secundaria que contiene las fases de
análisis y diseño de una programación orientada a objeto que a continuación
presentaremos:
Análisis y Diseño con Orientación a Objeto
CONTENIDO
1. ORGANIZACIÓN Y RESULTADOS DE LA ENTREVISTA
Para realizar esta primera etapa (análisis OO), 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 Instituto Profesional y Técnico de Veraguas (IPTV), ubicado en el
distrito de Santiago corregimiento de Canto del Llano.
Para llevar a cabo la Entrevista acudimos a dicho Centro, en el mismo
fuimos atendidos por el Sub-Director del plantel, el cual dio respuesta a
todas nuestras preguntas.
Observación:
Cal1: Registro académico del estudiante, en donde se visualizan los

estudiantes Aprobados y Fracasados en el bimestre, Fracasados a la
Fecha, sin Calificación y los Retirados. El mismo es revisado por el
coordinador.
Cal2: Contiene un informe mas preciso y detallado del rendimiento
de cada estudiante; el mismo se deriva del Cal1 después de su previa
revisión por parte del coordinador.
1.1 Las preguntas efectuadas fueron las siguientes:
1. ¿Existe en este plantel el Proceso de Administración

Escolar?
R/. En el plantel se da un proceso de Administración Escolar, pero de
manera manual porque el sistema educativo no permite llevar a cabo
un control automatizado.
Proyecto # 1 1
2. ¿Quiénes son los encargados de llevar el Proceso de

Administración Escolar enfocado al Desempeño Académico?
R/. Los encargado de llevar este proceso es la Comisión de
Rendimiento Escolar.
3. ¿Cómo se lleva a cabo en este plantel el Control de

Calificaciones?
R/. En este plantel el control de calificaciones se da de la siguiente
manera: Cada profesor presenta un resumen escolar de las
calificaciones bimestrales por asignatura, luego estas calificaciones
pasan a un historial por año.
4. ¿Cómo son identificadas las Áreas de deficiencias?
R/. Estas son identificadas por la Comisión de Rendimiento Académico.
Esto se lleva a cabo mediante un proceso, el cual resumiremos a
continuación:
Cada profesor entrega por bimestre una lista del promedio final de
los estudiantes; a esta lista se le llama Cal1.
Por cada materia existe un coordinador el cual lleva a cabo la
revisión del Cal1 entregados por cada profesor.
El coordinador entrega a la Comisión de Rendimiento Académico un
Cal2 el cual lleva la información de los estudiantes.
La Comisión de Rendimiento Académico pasa una copia a la
dirección y a la orientación.
La Orientación se encarga de identificar los motivos por la cual
existe deficiencia en los estudiantes.
5.¿Cómo se seleccionan los estudiantes de Cuadro de Honor?
Proyecto # 1 2
R/. Utilizando el proceso anterior Cal1, Cal2 se identifican los

estudiantes de cuadro de honor; generalmente el promedio es de 4.5
en adelante.
6. ¿Existe, en este plantel un proceso para evaluar la eficiencia

docente?
R/. En este plantel no existe un proceso para evaluar la eficiencia
docente.
7. ¿Cómo se calcula la estadística por salón en cuanto al

desempeño académico del estudiante?
R/. Mediante el Cal1 entregado por cada profesor se calcula la
estadística por salón en cuanto al desempeño académico del
estudiante.
2. UTILIDAD DE LA INFORMACIÓN
Es de mucha importancia todos estos datos recabados de la entrevista
realizada al Sub-Director encargado de este centro educativo, para poder
realizar un análisis detallado de un sistema de administración escolar y
confeccionar los respectivos diagramas UML que esta primera etapa
(análisis OO) requiere.
Por lo 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
detallado, con sus respectivos diagramas UML.
3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO

En el Instituto Profesional y Técnico de Veraguas (IPTV) 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
Proyecto # 1 3
deficiencias, las estadísticas por salón, puestos de honor, y evalúe el

desempeño eficiente de los docentes.
3.1. Definición del dominio

El dominio del problema esta basado en el enfoque orientado a objeto
de un sistema de Administración Escolar de Secundaria para atender
diversas necesidades que pueden presentar un centro educativo;
basándonos en este dominio se clasificaron las clases utilizadas.
4. OBJETIVOS DEL SISTEMA
4.1. Objetivo general

Analizar y Diseñar un sistema de Administración Escolar enfocado
al desempeño académico utilizando Orientación a Objetos y
representación UML.
4.2. Objetivos Específicos:

Identificar las áreas en la que los estudiantes presentan
deficiencias y mostrar las estadísticas por salón.
Llevar el control de las calificaciones por bimestre e historial por
año.
Determinar el desempeño excelente por docente.
Identificar el proceso para seleccionar a los estudiantes de cuadro
de honor.
5. LISTA DE REQUISITOS DEL SISTEMA

Llevar el control de calificaciones de un bimestre o historial por
año.
Sea capaz de identificar las áreas de deficiencia de los
estudiantes.
Proyecto # 1 4
El sistema permitirá identificar los cuadro de honor y la eficiencia

de los docentes.
 Mostrar la estadística por salón en cuanto a la cantidad de fracaso
y el desempeño satisfactorio de los estudiantes.
6. ANÁLISIS ORIENTADO A OBJETOS DEL SISTEMA
6.1. Identificación de las clases:

Para identificar las clases del dominio del problema utilizamos las
técnicas descritas en el documento de Miguel Ángel Abian.
6.1.1. Clases Involucradas:
Estudiante
Profesor Materia
Clases
Deficiente Calificaciones
Cuadro de Honor
6.2. Elaboración de Glosario de Términos Procedentes del

Dominio:
Esta etapa la omitimos, ya que sus términos son de uso común, ya
que se describen dentro de dicho proyecto.
6.3. Identificación de las Relaciones entre las clases:

Los estudiantes necesitan de las materias
Los estudiantes necesitan de los profesores
Los estudiantes tienen calificaciones.
El cuadro de honor necesita de las calificaciones.
Proyecto # 1 5
Algunos estudiantes son deficientes.

Los profesores entregan calificaciones.
Proyecto # 1 6
6.4. Diagrama de relaciones de las clases y sus atributos:
Clase
Estudiante
Nombre
Grado
Necesita
Necesitan
Alguno
Clase Profesor Clase Materia
s son Nombre
Nombre
Materia Nombre del
Cant. de estudiante Profesor
Calificaciones del Tiene Nivel Académico
estudiante.
Clase Clase
Deficiente Cuadro de Honor
Nombre de la Calificaciones
Nombre del Estudiante
Entreg
an
Necesit
Clase
Calificaciones
Calificaciones
Grado
6.5. Descripción de las clases del problema

Luego de haber abstraído las clases que formarán nuestro sistema,
se detallará a continuación el funcionamiento de las mismas con
sus atributos o variables de instancia.
Proyecto # 1 7
DESCRIPCIÓN DE CADA CLASE

CLASES ATRIBUTOS COMPORTAMIENTO
Principal El método de esta clase es el
Main en el cual se llama a las
otras clases las mismas son las
siguientes:
* Class Estudiante
* Class Profesor
* Class Materia
* Class Calificaciones
* Class CuadrodeHonor
* Class Deficientes
Estudiante * nomest: Almacena Los métodos de esta clase

el Nombre del serian los siguientes:
estudiante. * getNombre(): el cual
* grado: Almacena el devolverá el nombre del
nivel que cursa el estudiante.
estudiante. * getGrado(): el cual devolverá
* calificaciones: el grado que cursa el
Almacena las estudiante.
calificaciones de los
estudiantes.
Profesor * nomprof: Almacena Los métodos de esta clase

el nombre del profesor. serian los siguientes:
* cantestu: Almacena * getProf(): el cual devuelve el
la cantidad de nombre del profesor.
estudiantes. * getRep(): el cual devuelve la
* mate: Almacena la cantidad de estudiantes
materia que imparte el reprobados.
profesor. * getApro(): el cual devuelve la
cantidad de aprobados.
Materia * nommate: Los métodos de esta clase

Almacena el nombre serian los siguientes:
de la materia. * getMate(): el cual devolverá
* nomprofmate: el nombre de la materia.
Almacena el nombre * getProfmate(): el cual
del profesor que dicta devolverá el nombre del
la materia. profesor que dicta esa materia.
Proyecto # 1 8
Calificaciones * califica: Almacena Los métodos de esta clase

las calificaciones del serian los siguientes:
estudiante. * promBime(): este método
* nombestu: calculará el promedio bimestral
Almacena el nombre de las calificaciones obtenidas
del estudiante. en cada asignatura.
* promFin(): calculará el
promedio que llevará el
estudiante en el año,obtenida a
partir del método anterior.
CLASES ATRIBUTOS COMPORTAMIENTO

Cuadro de Honor * calif: Almacena las Esta clase contendrá el
calificaciones del siguiente método:
estudiante. * mayProm (): este
* nombest: Almacena método se encarga de
el nombre del obtener los estudiantes
estudiante. de cuadro de honor.
Deficiente Esta clase contendrá el

“No contiene siguiente método:
variables de * cantDefmat (): este
instancia” método se encarga de
obtener la cantidad de
estudiantes deficientes
de una determinada
materia.
Proyecto # 1 9
7. IDENTIFICACIÓN DE LOS ATRIBUTOS Y PROPIEDADES DE LAS

CLASES
En esta etapa procedemos a identificar los atributos y propiedades que
conforman el sistema mediante el Diagrama UML.
Proyecto # 1 10
7.1 A continuación diagrama UML de las clases
Class
Principal
main()
Class Class Class Class Class

Class
Estudiante Materia Calificaciones Cuadro de Deficiencia
Profesor
Honor
* float calif
* String * String
nomest * String * float califica * String nomest
nommate
* String grado nomprof * String nombestu
* String * mayProm () * cantDefmat
* float * int cantestu
()
* getNombre() * String mate * getMate() * promBime()
* getGrado() * getProfmate() * promFin()
* getProf()
* getRep()
* getApro()
Proyecto # 1 11
8. DIAGRAMA DE CASOS DE USOS DEL SISTEMA

8.1 Definición de Diagrama de Caso de Uso
Es una 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.
En todo análisis OO, es necesario diseñar diagramas de usos que nos
ayudan a desarrollar y visualizar un sistema.
8.2 Como una primera aproximación identificamos a los actores

que interactúan con el sistema:
Coordinador
Comisión de
Identificar Rendimiento
áreas de
deficiencias
Profesor
Orientación
Proyecto # 1 12
8.3 Caso de uso: Identificación de las áreas de deficiencias
Entrega
Cal1
Profesor
Coordinad
or revisa
Cal1
Genera
reporte
(Cal2)
Reporte
de
Comisió deficien
n de cia
rendimie
nto
académi
Orientación
Recibe
información
de
Dirección rendimiento
Recibe
información
de
rendimiento
Proyecto # 1 13
Proyecto # 1 14
9. COEVALUACIÓN
YORISBETH CALLES
Para la elaboración de este proyecto obtuve nuevos conocimiento en
cuanto a un Análisis y Diseño de Orientado a Objeto, la confección de
diagramas UML, aclare dudas sobre los conceptos de clases, objeto,
métodos, ya que necesitaba de ellos para poder continuar con el proyecto
como trabaja con un dominio.
Este proyecto es de mucha importancia, por que para ser una buena
programadora tendré presente antes de programar, analizar primero el
dominio y después programar.
ROMAN GONZÁLEZ
¿Qué conocimientos previos fueron esenciales?

Los conocimientos previos que fueron esenciales fueron los de tener una
base en programación c++ para tener o hacer una relación con funciones
de c++ y métodos en java.
Los conocimientos adquiridos al leer los documentos o recursos brindados
para este proyecto. conceptos previos como clases, métodos, objetos; que
a la vez se fueron reforzando en la elaboración de este trabajo.
Tener una idea de como se lleva el control de calificaciones de una
escuela.
¿Qué importancia tiene para su formación profesional?

La importancia que tiene es que nos a enseñado a analizar mas. De esta
forma cuando se nos presente un problema, no empezaremos a resolverlo
sin antes analizarlo y buscar la forma correcta de resolverlo.
¿Qué utilidad tiene el trabajo realizado?
Proyecto # 1 15
La utilidad que tiene este trabajo es que por el momento la mayoría de

las escuelas llevan un control de rendimiento académico de forma
manual, porque así el ministerio se los exige, y cuando llegue el momento
en que las escuelas empiecen a implementar un control mas
sistematizado, cuenten con una base para resolver este problema, que
podría ser uno de nuestros análisis.
ANNETH MANZANÉ
 Los conocimientos nuevos que adquirí, a parte de entender mejor

sobre la elaboración del diagrama de relaciones y el diagrama UML;
fue aprender sobre los diagrama de caso de uso, al igual que analizar y
diseñar un sistema enfocado al desempeño académico de los
estudiantes de un centro educativo.
 Los conocimientos previos esenciales fueron explorar y analizar las
WebQuest, la documentación de Miguel Ángel Abían, también las fases
de análisis Orientado a Objetos en cuanto al dominio de un sistema, las
clases, los atributos, métodos, etc.
 Este proyecto es muy importante para mi ya que a través de él e
adquirido nuevos conocimientos que van a ser de mucha utilidad en
caso de que tenga que analizar y diseñar un programa orientado a
objeto.
 Este proyecto es de gran utilidad, ya que el mismo puede servir para
realizar otras asignaciones, fortalecer los conceptos de análisis para
diseñar un sistema y a la vez que pueda ser implementado en un
Centro Educativo Secundario.
FÁTIMA GONZÁLEZ
¿Qué nuevos conocimientos se lograron?

Después de la elaboración del proyecto he adquirido nuevos
conocimientos como la elaboración de los diagramas UML, así como
Proyecto # 1 16
identificar los conceptos de clases, objetos y métodos los cuales su

definición al inicio eran un poco confusas, hoy día estos términos han sido
aclarados permitiéndome un mayor entendimiento sobre la programación
orientada a objetos.
¿Qué conocimientos previos fueron esenciales?

Manejar los conceptos de programación orientada a objeto bajo la
plataforma de java, que las clases en java es un conjunto de variables y
métodos encapsulados que realizan una tarea especifica, los objetos es
una variable que puede ser referencia a un método de una clase y los
métodos agrupan pasos y procesos para resolver una tarea en especial,
estos son algunos de los conocimientos previos que fueron esenciales y
de mucha utilidad para la elaboración de este proyecto.
¿Qué importancia tiene para su formación profesional?

Es de mucha importancia ya que contribuye a ampliar mis conocimientos
en la rama de informática permitiéndome mayor competitividad en el
mundo laboral ya que java es una herramienta de programación
actualizada y moderna utilizada en los diseños de muchos sistemas
informáticos.
¿Qué utilidad tiene el trabajo realizado?

Es de mucha utilidad porque me da las bases para desarrollar mis futuras
aplicaciones, permitiendo manejar los conceptos de la programación
estructurada en java.
Proyecto # 1 17
10. REFLEXIONES FINALES

10.1 ¿Cómo fue la labor de los integrantes?
Después de haber leído los aspectos que abarcarían el proyecto, sus
puntos a evaluar y visitados los recursos ofrecidos por parte del
facilitador del curso, los integrantes del grupo colaboraron de manera
organizada y aportaron sus ideas sobre la fase de análisis tratada en el
documento de Miguel Ángel Abían, las cuales fueron muy acogidas por
todos los integrantes del grupo. A partir de allí y llevando paso a paso
cada punto a desarrollar, se llevo a cabo la elaboración del proyecto
que hoy le presentamos, esperando sea lo solicitado.
10.2 ¿Cuál fue la parte más difícil y por qué?

A continuación le describimos los puntos que fueron más difíciles:
Uno de ellos fue la elaboración del Diagrama de Caso de Uso; allí se
nos presento dificultad ya que no teníamos un conocimiento previo de
su confección y utilidad.
Se nos hizo difícil encontrar las clases involucradas, ya que había
momentos en que pensábamos que teníamos todas las clases del
problema, pero de pronto surgían otras ideas, las cuales nos llevaban a
involucrar otras clases, y teníamos que reestructurar nuestra solución.
Otro de los puntos que se nos hizo un poco difícil fue las
descripciones de las clases, esto se dio porque no teníamos una idea
clara de lo que en realidad el sistema tenía como objetivo.
“Pero como en la vida nada es inalcanzable y querer es poder se logro
sacar hacia delante estos puntos, no de manera eficaz pero
consideramos que muy eficientes, todo esto se realizo con la
colaboración de todos los integrantes”
10.3 ¿Cuál fue la metodología para lograr los objetivos de este

trabajo?
Proyecto # 1 18
El aporte de ideas de parte de los integrantes del grupo, fue una
ayuda de mucha utilidad ya que se generalizo el proceso a seguir para
la elaboración de dicho proyecto.
Desarrollo del Mapa Conceptual de la etapa de Análisis Orientado a
Objetos.
Utilizamos un itinerario de actividades para organizar los pasos a
seguir en el proyecto, como por ejemplo: La aplicación de la entrevista
en el Instituto Profesional y Técnico de Veraguas.
Desarrollo de análisis de diagramas UML del sistema.
“Y de esta manera llegamos a recopilar todos los datos solicitado por el
profesor”
11. MAPA CONCEPTUAL DE LA FASE DE ANÁLISIS TRATADA EN EL

DODUMENTO DE MIGUEL ÁNGEL ABIÁN
Proyecto # 1 19
Proyecto # 1 20
Proyecto # 1 21
WEBGRAFIAS
-Documento pdf. Miguel Ángel Abian. Análisis OO.

http://www.javahispano.org/tutorials.item.action?id=25
-Herramienta para diseño de mapa conceptual
http://cmap.ihmc.us/
-Tutorial UML recomendado para la captación rápida de los conceptos y
aplicación de esta tecnología:
http://www.clikear.com/manuales/uml/
http://www.esnips.com/doc/5ae972fd-837f-4ab4-a3c0-
e5a575567699/Tutorial-de-UML/?widget=documentlcon
Dirección del Mapa Conceptual
http://es.geocities.com/orientacionobjeto/analisis.html
Proyecto # 1 22
CONCLUSIÓN
El desarrollo de este trabajo nos ha permitido ampliar nuestros

conocimientos acerca de la programación orientada a objetos bajo el
dominio del lenguaje Java.
Familiarizarse con la estructura de un programa en Java facilita el desarrollo
de aplicaciones para automatizar los sistemas en general ya que permite,
analizar y diseñar soluciones para los problemas y necesidades de nuestra
vida diaria con una visión cercana a la realidad sin contar que la reutilización
de clases y métodos en Java le facilita el trabajo al programador.
Proyecto # 1 23
Proyecto # 1 24
ANEXO
Proyecto # 1 25
RESUMEN INDIVIDULES
YORISBTEH CALLES
Diagrama UML
El Lenguaje de Modelamiento Unificado (Uml). Es un lenguaje gráfico para
visualizar, especificar y documentar cada una de las partes que comprende
el desarrollo de software.
El documento contempla el estudio de tres diagramas:
 Modelamiento de Clases
 Casos de Uso
 Diagrama de Interacción
Modelos de clase:
Un diagrama de clases sirve para visualizar las relaciones entre las clases
que involucran el sistema.
Un diagrama de clases esta compuesto por los siguientes elementos:
 Clase: atributos, métodos y visibilidad.
 Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Elementos:
Clase: Es la unidad básica que encapsula toda la información de un Objeto
(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 (o
variables de instancia) que caracterizan a la
Clase (pueden ser private, protected o
public).
 Inferior: Contiene los métodos u
operaciones, los cuales son la forma como interactúa el objeto
Proyecto # 1 26
con su entorno (dependiendo de la visibilidad: private, protected

o public).
Atributos: Los atributos o características de una Clase pueden ser de tres

tipos.
 public (+, ): Indica que el atributo será visible tanto dentro

como fuera de la clase, es decir, es accsesible 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 como

é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 accsesible 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 si podrá ser accesado por métodos
de la clase además de métodos de las subclases que se deriven
(ver herencia).
Relaciones entre Clases:
Proyecto # 1 27
Ahora ya definido el concepto de Clase, es necesario explicar como se

pueden interrelacionar dos o más clases (cada uno con características y
objetivos diferentes).
En UML, la cardinalidad de las relaciones indica el grado y nivel de

dependencia, se anotan en cada extremo de la relación 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):
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 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. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la
aplicación, tenemos dos posibilidades: por valor, por referencia.
La La
composició agregación
n (por Valor) (por
se destaca Referencia) se
Proyecto # 1 28
 Asociación:
La relación entre clases conocida como

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 o Instanciación (uso):
Representa un tipo de relación muy

particular, en la que una clase es instanciada
(su instanciación es dependiente de otro objeto/clase). Se denota por una
flecha punteada.
Casos de Uso (Use Case)
El 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 (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
 Actor.
 Casos de Uso.
 Relaciones de Uso, Herencia y Comunicación.
Elementos
 Actor: Una definición previa, es que un Actor es un rol
que un usuario juega con respecto al sistema. Es
Proyecto # 1 29
importante destacar el uso de la palabra rol, pues con esto se

especifica que un Actor no necesariamente representa a una persona
en particular, sino más bien la labor que realiza frente al sistema.
 Caso 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:
 Asociación
Es el tipo de relación más básica que indica la invocación desde

un actor o caso de uso a otra operación (caso de uso). Dicha
relación se denota con una flecha simple.
 Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual

una clase depende de otra, es decir, se instancia (se crea). Dicha
relación se denota con una flecha punteada.
 Generalización
Este tipo de relación es uno de los más utilizados, cumple una

doble función dependiendo de su estereotipo, que puede ser de
Uso (<<uses>>) o de Herencia (<<extends>>).
 extends: Se recomienda utilizar 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
Proyecto # 1 30
uso y no se desea mantener copiada la descripción de la

característica.
Ejemplo de una diagrama de uso:
Proyecto # 1 31
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.
Los componentes de un diágrama de interacción son:
 Un Objeto o Actor.
 Mensaje de un objeto a otro objeto.
 Mensaje de un objeto a si mismo.
Elementos
 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 Objeto:
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.
Proyecto # 1 32
Ejemplo de modelo estático:
Proyecto # 1 33
ROMAN GONZÁLEZ
TUTORIAL UML
UML entrega una forma de modelar cosas conceptuales como lo son
procesos de negocio y funciones de sistema, además de cosas concretas
como lo son escribir clases en un lenguaje determinado, esquemas de base
de datos y componentes de software reusables.
Modelo de clases :
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Objeto: un objeto es una instancia de una clase.
Encapsulamiento: El encapsulamiento consiste en unir en la Clase las

características y comportamientos, esto es, las variables y métodos. Es tener
todo esto es una sola entidad.
Abstracción: La abstracción consiste en captar las características

esenciales de un objeto, así como su comportamiento.
Entornos que pueden ser de estudios para crear una clase : una Casa, un
Auto, una Cuenta Corriente, etc.
Definición de una clase: Es la unidad básica que encapsula toda la

información de un Objeto. A través de ella podemos modelar el entorno en
estudio.
Una clase es una agrupación de datos (variables ) y de funciones que operan

sobre esos datos (metodos).

divisiones:
Proyecto # 1 34
Nombre clase
Atributos
Operaciones o
métodos

 Intermedio: Contiene los atributos (o variables de instancia) que
caracterizan a la Clase (pueden ser private, protected o public).
 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).
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.
 Métodos:
Los métodos u operaciones de una clase son la forma en como ésta
interactúa con su entorno.
Tipos de atributos y métodos
Proyecto # 1 35
Tipos Descripcion
Indica que el atributo será visible tanto
public (+, )
dentro como fuera de la clase, es decir, es
Indica quedesde
accsesible el atributo sólo será accesible
todos lados.
Atribut private (-, )
desde dentro de la clase (sólo sus métodos
os
protected (#, lo pueden
Indica queaccesar).
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).
Indica que el método será visible tanto
public (+, )
dentro como fuera de la clase, es decir, es
accsesible
Indica quedesde todos lados.
el método sólo será accesible
private (-, )
Método desde dentro de la clase (sólo otros
s protected métodos
(#, Indica de la
que el clase lo pueden
método acceder).
no será accesible
desde fuera de la clase, pero si podrá ser
) accesado por métodos de la clase además
de métodos de las subclases que se deriven
(ver herencia).

Cardinalidad: En UML, la cardinalidad de las relaciones indica el grado y
nivel de dependencia, se anotan en cada extremo de la relación y éstas
pueden ser:
 0 o muchos: 0..* (0..n)
Proyecto # 1 36
Herencia (Especialización/Generalización):
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 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. Cuando se requiere componer objetos que son
instancias de clases definidas por el desarrollador de la aplicación,
tenemos dos posibilidades:
1. Por Valor: Es un tipo de relación estática, en donde el tiempo

de vida del objeto incluido esta condicionado por el tiempo de
vida del que lo incluye. Este tipo de relación es comúnmente
llamada Composición (el Objeto base se construye a partir del
objeto incluido, es decir, es "parte/todo").
2. Por Referencia: Es un tipo de relación dinámica, en donde el
tiempo de vida del objeto incluido es independiente del que lo
incluye. Este tipo de relación es comúnmente llamada
Agregación (el objeto base utiliza al incluido para su
funcionamiento).
En donde se destaca que:
3. Un Almacén posee Clientes y Cuentas (los rombos van en el

objeto que posee las referencias).
Proyecto # 1 37
4. Cuando se destruye el Objeto Almacén también son destruidos

los objetos Cuenta asociados, en cambio no son afectados los
objetos Cliente asociados.
5. La composición (por Valor) se destaca por un rombo relleno.
6. La agregación (por Referencia) se destaca por un rombo
transparente.
La flecha en este tipo de relación indica la navegabilidad del

objeto refereniado. Cuando no existe este tipo de particularidad la
flecha se elimina.
Asociación:
La relación entre clases conocida como 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.
Ejemplo:
Un cliente puede tener asociadas muchas Ordenes de Compra, en

cambio una orden de compra solo puede tener asociado un cliente.
Dependencia o Instanciación (uso):
Representa un tipo de relación muy particular, en la que una clase

es instanciada (su instanciación es dependiente de otro
objeto/clase). Se denota por una flecha punteada.
Proyecto # 1 38
El uso más particular de este tipo de relación es para denotar la

dependencia que tiene una clase de otra, como por ejemplo una
aplicación grafica que instancia una ventana (la creación del Objeto
Ventana esta condicionado a la instanciación proveniente desde el
objeto Aplicación):
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.
Los componentes de un diagrama de interacción son:

6.Un Objeto o Actor.
Mensaje de un objeto a otro objeto.
Mensaje de un objeto a si mismo
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 Objeto:
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:
Proyecto # 1 39
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.
Casos de Uso (Use Case)
El 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 (operaciones o casos de uso).
 Actor.
 Casos de Uso.
Actor:
Un Actor es un rol que un usuario juega con respecto al sistema.
Un Actor no necesariamente representa a una persona en particular, sino

más bien la labor que realiza frente al sistema.
Caso 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.
Proyecto # 1 40
Relaciones:
Tipos de Símbolo Descripción
Relaciones
Es el tipo de relación más básica que

Asociación indica la invocación desde un actor o caso
de uso a otra operación (caso de uso).
Dicha relación se denota con una flecha
simple.
Dependencia o Es una forma muy particular de relación

Instanciación entre clases, en la cual una clase
depende de otra, es decir, se instancia
(se crea). Dicha relación se denota con
una flecha punteada.
Este tipo de relación es uno de los más

utilizados, cumple una doble función
dependiendo de su estereotipo, que
puede ser de Uso (<<uses>>) o de
Generalización
Herencia (<<extends>>).
Este tipo de relación esta orientado

exclusivamente para casos de uso (y no
para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro

(características). uses: Se recomienda utilizar cuando se tiene un conjunto
Proyecto # 1 41
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.
Tutorial UML
UML (Unified Modeling Language) es un lenguaje que permite modelar,

construir y documentar los elementos que forman un sistema software
orientado a objetos. Se ha convertido en el estándar de facto de la industria,
debido a que ha sido impulsado por los autores de los tres métodos más
usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim
Rumbaugh.
Uno de los objetivos principales de la creación de UML era posibilitar el

intercambio de modelos entre las distintas herramientas CASE orientadas a
objetos del mercado. Para ello era necesario definir una notación y
semántica común.
Modelos
Un modelo representa a un sistema software desde una perspectiva

específica. Al igual que la planta y el alzado de una figura en dibujo técnico
nos muestran la misma figura vista desde distintos ángulos, cada modelo
nos permite fijarnos en un aspecto distinto del sistema.
Clases:
Una clase se representa mediante una caja subdividida en tres partes: En la
superior se muestra el nombre de la clase, en la media los atributos y en la
inferior las operaciones.
Ejemplo de una clase Lámpara
Lámpara
mensaje
Prender()
Apagar()
Proyecto # 1 42
Objetos
Un objeto se representa de la misma forma que una clase. En el
compartimiento superior aparecen el nombre del objeto junto con el nombre
de la clase subrayados.
Asociaciones
Las asociaciones entre dos clases se representan mediante una línea que las
une. La línea puede tener una serie de elementos gráficos que expresan
características particulares de la asociación.
Nombre de la Asociación y Dirección

El nombre de la asociación es opcional y se muestra como un texto que está
próximo a la línea. Se puede añadir un pequeño triángulo negro sólido que
indique la dirección en la cual leer el nombre de la asociación.
Ejemplo:
Manda sobre
JEFE EMPLEADO
Herencia
La relación de herencia se representa mediante un triángulo en el extremo
de la relación que corresponde a la clase más general o clase “padre”.
MAMIFEROS
Perro Gato
Diagrama de Casos de Uso
Proyecto # 1 43
Un Diagrama de Casos de Uso muestra la relación entre los actores y los ca-
sos de uso del sistema. Representa la funcionalidad que ofrece el sistema en
lo que se refiere a su interacción externa. En el diagrama de casos de uso se
representa también el sistema como una caja rectangular con el nombre en
su interior. Los casos de uso están en el interior de la caja del sistema, y los
actores fuera, y cada actor está unido a los casos de uso en los que participa
mediante una línea.
Estacion de gasolina
Apagar el auto
Hacer pedido
Cliente
Entregar dinero
Depositar gasolina
Recibir pago
Proyecto # 1 44
Empleado
Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:
actores, casos de uso y relaciones entre casos de uso.
Actores
Un actor es algo con comportamiento, como una persona (identificada por un
rol), un sistema informatizado u organización, y que realiza algún tipo de
interacción con el sistema.. Se representa mediante una figura humana
dibujada con palotes.
Casos de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se

producen entre un actor y el sistema, cuando el actor usa el sistema para
llevar a cabo una tarea específica.
Relaciones entre Casos de Uso
Un caso de uso, en principio, debería describir una tarea que tiene un

sentido completo para el usuario. Sin embargo, hay ocasiones en las que es
útil describir una interacción con un alcance menor como caso de uso. La
razón para utilizar estos casos de uso no completos en algunos casos, es
mejorar la comunicación en el equipo de desarrollo, el manejo de la
documentación de casos de uso.
Diagramas de Interacción
En los diagramas de interacción se muestra un patrón de interacción entre
objetos. Hay dos tipos de diagrama de interacción, ambos basados en la
Proyecto # 1 45
misma información, pero cada uno enfatizando un aspecto particular:

Diagramas de Secuencia y Diagramas de Colaboración.
 Diagrama de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la
secuencia temporal de eventos. En particular, muestra los objetos
participantes en la interacción y los mensajes que intercambian ordenados
según su secuencia en el tiempo.
 Diagrama de Colaboración
Un Diagrama de Colaboración muestra una interacción organizada
basándose en los objetos que toman parte en la interacción y los
enlaces entre los mismos (en cuanto a la interacción se refiere). A
diferencia de los Diagramas de Secuencia, los Diagramas de
Colaboración muestran las relaciones entre los roles de los objetos.
Proyecto # 1 46
Fátima González
UML
UML (Unified Modeling Language) es un lenguaje que permite modelar, cons-
truir y documentar los elementos que forman un sistema software orientado
a objetos. Esta notación ha sido ampliamente aceptada debido al prestigio
de sus creadores y debido a que incorpora las principales ventajas de cada
uno de los métodos particulares en los que se basa (principalmente Booch,
OMT y OOSE).
Los modelos de UML que se tratan en esta parte son los siguientes:
 Diagrama de Estructura Estática.
 Diagrama de Casos de Uso.

 Diagrama de Secuencia.
 Diagrama de Colaboración.
 Diagrama de Estados.
MODELO DE 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:
CLASE
Una clase se representa mediante una caja subdividida en tres partes: En la
superior se muestra el nombre de la clase, en la media los atributos y en la
inferior 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.
Proyecto # 1 47
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, estos son:
 public (+, ): Indica que el atributo será visible tanto dentro como
fuera de la clase, es decir, es accsesible 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 como
é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 accesesible 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 acceder).
 protected (#, ): Indica que el método no será accesible desde fuera

de la clase, pero si podrá ser accesado por métodos de la clase
además de métodos de las subclases que se deriven (ver herencia).
OBJETOS:
Un objeto se representa de la misma forma que una clase. según la
siguiente 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.
Proyecto # 1 48
RELACIONES ENTRE CLASES:

Antes es necesario explicar el concepto de cardinalidad de relaciones: En
UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia,
se anotan en cada extremo de la relación y éstas pueden ser:
 0 o muchos: 0..* (0..n)
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 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. Cuando
se requiere componer objetos que son instancias de clases definidas por
el desarrollador de la aplicación, tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del
objeto incluido esta condicionado por el tiempo de vida del que lo incluye.
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de
vida del objeto incluido es independiente del que lo incluye. Este tipo de
relación es comúnmente llamada Agregación.
Asociación:
Proyecto # 1 49

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.
Ejemplo:
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio

una orden de compra solo puede tener asociado un cliente.

Representa un tipo de relación muy particular, en la que una clase es
instanciada (su instanciación es dependiente de otro objeto/clase). Se
denota por una flecha punteada.
CASOS PARTICULARES:
 Clase Abstracta: Una clase 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: Una 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. El ejemplo más típico es el caso de un Diccionario en
donde una llave o palabra tiene asociado un significado, pero en este
caso las llaves y elementos pueden ser genéricos.
Proyecto # 1 50
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.
Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen
las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama
Estático de Clases o el de Casos de Uso (son diferentes).

Elementos
El rectángulo
representa una
Objeto/Actor: instancia de un
objeto en particular,
y la línea punteada
Se representa por
Mensaje a Otro Objeto: una flecha entre un
objeto y otro,
representa la
llamada de un
Mensaje al Mismo Objeto: No solo llamadas a

métodos de objetos
externos pueden
realizarse, también
es posible visualizar
llamadas a métodos
Proyecto # 1 51
CASOS DE USO (USE CASE)

El 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 (operaciones o casos de uso).
 Actor.
 Casos de Uso.
ACTOR:
Una definición previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues
con esto se especifica que un Actor no necesariamente representa a una
persona en particular, sino más bien la labor que realiza frente al sistema.
CASO 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:
Asociación
Proyecto # 1 52
Es el tipo de relación más básica que indica la invocación desde un actor

o caso de uso a otra operación (caso de uso). Dicha relación se denota
con una flecha simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relación se denota
con una flecha punteada.
Generalización
Este tipo de relación es uno de los más utilizados, cumple una doble
función dependiendo de su estereotipo, que puede ser de Uso
(<<uses>>) o de Herencia (<<extends>>).
Como una primera aproximación identificamos a los actores que interactúan
con el sistema:
Identificación de Casos de Uso

La identificación de casos de uso requiere un conocimiento medio acerca
de los requisitos, y se basa en la revisión de los documentos de requisitos
existentes, y en el uso de la técnica de brainstorming entre los miembros
del equipo de desarrollo.
Como guía para la identificación inicial de casos de uso hay dos métodos:
a) Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la
organización.
2. Para cada actor, identificar los procesos que inicia o en los que
participa.
Proyecto # 1 53
b) Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a tener que
responder.
2. Relacionar los eventos con actores y casos de uso.
Identificación de los Límites del Sistema
En la descripción de un caso de uso se hace referencia en todo momento
al “sistema”. Para que los casos de uso tengan un significado completo es
necesario que el sistema esté definido con precisión.
Al definir los límites del sistema se establece una diferenciación entre lo
que es interno y lo que es externo al sistema. El entorno exterior se
representa mediante los actores.
Ejemplos de sistemas son:
 El hardware y software de un sistema informático.
 Un departamento de una organización.
 Una organización entera.
Proyecto # 1 54
ANNETH MANZANÉ
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 orientado a objetos..
Un modelo representa a un sistema software desde una perspectiva
específica.
Los modelos de UML que se presentarán en este resumen son los siguientes:
 Diagrama de Clase
 Diagrama de Casos de Uso.
 Diagrama de Estados.
 Diagrama de Componentes
DIAGRAMA DE MODELO DE CLASES

que involucran el sistema, las cuales pueden ser asociativas, de herencia, de
uso y de contenimiento.
ELEMENTOS DE UNA CLASE

Clase
Es la unidad básica que encapsula toda la información de un Objeto (un

objeto es una instancia de una clase).
divisiones: el nombre de la clase, sus atributos y operaciones ó
métodos.
Proyecto # 1 55
Atributos:
Los atributos o características de una Clase pueden ser de tres
tipos que son:
public (+, ): Indica que el atributo será accesible desde

todas las clases
private (-, ): Indica que el atributo sólo será accesible dentro

de la clase o sea que sólo sus métodos pueden acceder.
protected (#, ): Indica que el atributo no será accesible
fuera de la clase, pero si podrá ser accesado por métodos de la
clase.
Métodos:

interactúa con su entorno, éstos pueden tener las características:
public (+, ): Indica que el método será accesible desde

todas las clases.
private (-, ): Indica que el método sólo será accesible

dentro de la clase o sea que sólo otros métodos de la clase lo
pueden acceder.
protected (#, ): Indica que el método no será accesible

fuera de la clase, pero si podrá ser accesado por métodos de
la clase.
Proyecto # 1 56

En UML, la cardinalidad de las relaciones indica el grado y nivel de
dependencia, se anotan en cada extremo de la relación 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).
Objeto
Un objeto se representa de la misma forma que una clase. En el

compartimiento superior aparecen el nombre del objeto junto con el
nombre de la clase subrayados, según la siguiente 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.
Elementos Comunes a Todos los Diagramas
 Notas:
Es un modo de indicar información en un formato libre, cuando la

notación del diagrama en cuestión no nos permite expresar dicha
información de manera adecuada. Puede contener restricciones,
comentarios, el cuerpo de un procedimiento, etc; por ejemplo:
 Herencia (Especialización/Generalización):
Proyecto # 1 57
una Super Clase. La relación de herencia se representa mediante un
triángulo en el extremo de la relación que corresponde a la clase más
general o clase “padre”.
 Agregación:
Cuando se requiere componer objetos que son instancias de clases

definidas por el desarrollador de la aplicación, tenemos dos
posibilidades:
1. Por Valor: Es un tipo de relación estática, en donde el

tiempo de vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye. Este tipo de relación es
comúnmente llamada Composición.
2. Por Referencia: Es un tipo de relación dinámica, en
donde el tiempo de vida del objeto incluido es
independiente del que lo incluye. Este tipo de relación es
comúnmente llamada Agregación.
Asociación:

objetos que colaboran entre si y el tiempo de vida de un objeto no
depende del otro.
Multiplicidad
La multiplicidad es una restricción que se pone a una asociación, que
limita el número de instancias de una clase que pueden tener esa
asociación con una instancia de la otra clase.
Proyecto # 1 58
Navegabilidad:
Significa que es posible "navegar" desde el objeto de la clase origen
hasta el objeto de la clase destino. Se trata de un concepto de diseño,
que indica que un objeto de la clase origen conoce al (los) objeto(s) de
la clase destino, y por tanto puede llamar a alguna de sus operaciones.
Dependencia o Instanciación (uso):
El uso más particular de este tipo de relación es para denotar la

dependencia que tiene una clase de otra.
Casos Particulares:
 Clase Abstracta:
Una clase abstracta se denota con el nombre de la clase y de los

métodos con letra "itálica".
 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.
En los diagramas de interacción se muestra un patrón de interacción entre
objetos.
Hay dos tipos de diagrama de interacción, ambos basados en la misma
información, pero cada uno enfatizando un aspecto particular: Diagramas de
Secuencia y Diagramas de Colaboración.
 Diagrama de Secuencia:
Proyecto # 1 59
Un diagrama de Secuencia muestra una interacción ordenada según

la secuencia temporal de eventos. En particular, muestra los objetos
participantes en la interacción y los mensajes que intercambian
ordenados según su secuencia en el tiempo.
 Diagrama de Colaboración:
Un Diagrama de Colaboración muestra una interacción organizada

basándose en los objetos que toman parte en la interacción y los
enlaces entre los mismos (en cuanto a la interacción se refiere). A
diferencia de los Diagramas de Secuencia, muestran las relaciones
entre los roles de los objetos.
Componentes de un diagrama de interacción son:

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 Objeto:
Se representa por una flecha entre un objeto y otro, representa la

llamada de un método de un objeto en particular.
 Mensaje al Mismo Objeto:
No solo llama a métodos de objetos externos, también visualiza

llamadas a métodos desde el mismo objeto en estudio.
Proyecto # 1 60
DIAGRAMA 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.
Los casos de uso están en el interior de la caja del sistema, y los actores
fuera, y cada actor está unido a los casos de uso en los que participa
Actor:
Un Actor es un rol que un usuario juega con respecto al sistema. Un

Actor no necesariamente representa a una persona en particular, sino
más bien la labor que realiza frente al sistema.
Caso 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 de otro caso de uso.
Relaciones:
1. Asociación
un actor o caso de uso a otra operación (caso de uso).
2. Dependencia o Instanciación

una clase depende de otra, es decir, se instancia (se crea).
Proyecto # 1 61
3. Generalización

Este tipo de relación esta orientado exclusivamente para casos
de uso (y no para actores).

uso.
Aquí se presenta un diseño completo del diagrama Caso de Uso:
DIAGRAMAS DE ESTADO
Un Diagrama de Estados muestra la secuencia de estados por los que
pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien
Proyecto # 1 62
todo el sistema. En él se indican qué eventos hacen que se pase de un

estado a otro y cuáles son las respuestas y acciones que genera.
Modelado Físico De Un Sistema OO
 Componentes: Los componentes pertenecen al mundo físico, es
decir, representan un bloque de construcción al modelar aspectos
físicos de un sistema. Una característica básica de un componente
es que: “debe definir una abstracción precisa con una interfaz bien
definida, y permitiendo reemplazar fácilmente los componentes
más viejos con otros más nuevos y compatibles.”
En UML todos los elementos físicos se modelan como componentes.
 Interfaces: Tanto los servicios propios de una clase como los

de un componente, se especifican a través de una Interfaz. Por
ejemplo, todas las facilidades más conocidas de los sistemas
operativos, basados en componentes, utilizan las interfaces
como lazo de unión entre unos componentes y otros.
 Tipos de componentes:
Existen básicamente tres tipos de componentes:

 Componentes de despliegue: componentes
necesarios y suficientes para formar un sistema
ejecutable.
 Componentes producto del trabajo: Consisten en
cosas como archivos de código fuente y de datos a
partir de los cuales se crean los componentes de
despliegue.
 Componentes de ejecución: son componentes que
se crean como consecuencia de un sistema en
ejecución.
 Organización de componentes:
Los componentes se pueden agrupar en paquetes de la

misma forma que se organizan las clases. Además se pueden
Proyecto # 1 63
especificar entre ellos relaciones de dependencia,

generalización, asociación (incluyendo agregación), y
realización.
 Despliegue
 Nodos: Es un elemento físico, que existe en tiempo de

ejecución y representa un recurso computacional que
generalmente tiene alguna memoria y, a menudo, capacidad
de procesamiento.
 Nodos y componentes: Los nodos y los componentes tienen

características parecidas. Vamos a ver con más detalle cuales
son los parecidos y las diferencias entre los componentes y los
nodos.
 Parecidos:
Ambos tienen nombre
Pueden participar en relaciones de dependencia,
generalización y asociación.
Ambos pueden anidarse
Ambos pueden tener instancias
Ambos pueden participar en interacciones
Diferencias
Los Nodos Los Componentes

Son los elementos donde se ejecutan los componentes.
Son los elementos que participan en la ejecución de un

sistema.
Representan el despliegue físico de los componentes.
Representan el empaquetamiento físico de los elementos
lógicos.
DIAGRAMAS DE COMPONENTES
Proyecto # 1 64
Un diagrama de componentes muestra la organización y las dependencias

entre un conjunto de componentes.
PROCESO DE DESARROLLO
Cuando se va a construir un sistema software es necesario conocer un
lenguaje de programación, pero con eso no basta. Si se quiere que el sistema
sea robusto y mantenible es necesario que el problema sea analizado y la
solución sea cuidadosamente diseñada. Si se sigue un proceso de desarrollo
que se ocupa de plantear cómo se realiza el análisis y el diseño, y cómo se
relacionan los productos de ambos, entonces la construcción de sistemas
software va a poder ser planificable y repetible, y la probabilidad de obtener
un sistema de mejor calidad al final del proceso aumenta
considerablemente, especialmente cuando se trata de un equipo de
desarrollo formado por varias personas.
Proyecto # 1 65
CONSENSO
Diagrama UML
El Lenguaje de Modelamiento Unificado (Uml). Es un lenguaje gráfico
para visualizar, especificar y documentar cada una de las partes que
comprende el desarrollo de software.
El documento contempla el estudio de tres diagramas:
 Modelamiento de Clases
 Casos de Uso

divisiones:

 Intermedio: Contiene los atributos (o variables de instancia) que
caracterizan a la Clase (pueden ser private, protected o public).
 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).
Modelo de clases :
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Objeto: un objeto es una instancia de una clase.
Atributos:
Los atributos o características de una Clase pueden ser de tres tipos que son:
Proyecto # 1 66
public (+, ): Indica que el atributo será accesible desde

todas las clases
private (-, ): Indica que el atributo sólo será accesible dentro

de la clase o sea que sólo sus métodos pueden acceder.
protected (#, ): Indica que el atributo no será accesible
fuera de la clase, pero si podrá ser accesado por métodos de la
clase.
Métodos:

interactúa con su entorno, éstos pueden tener las características:
public (+, ): Indica que el método será accesible desde todas

las clases.
private (-, ): Indica que el método sólo será accesible dentro

de la clase o sea que sólo otros métodos de la clase lo pueden
acceder.
protected (#, ): Indica que el método no será accesible fuera

de la clase, pero si podrá ser accesado por métodos de la clase.
Encapsulamiento: El encapsulamiento consiste en unir en la Clase las

características y comportamientos, esto es, las variables y métodos. Es tener
todo esto es una sola entidad.
Abstracción: La abstracción consiste en captar las características

esenciales de un objeto, así como su comportamiento.
RELACIONES ENTRE CLASES:

Proyecto # 1 67
Antes es necesario explicar el concepto de cardinalidad de relaciones: En

UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia,
se anotan en cada extremo de la relación y éstas pueden ser:
 0 o muchos: 0..* (0..n)
una Super Clase, por ende la Subclase además de poseer sus propios
métodos y atributos, poseerá las 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. Cuando
se requiere componer objetos que son instancias de clases definidas por
el desarrollador de la aplicación, tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del
objeto incluido esta condicionado por el tiempo de vida del que lo incluye.
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de
vida del objeto incluido es independiente del que lo incluye. Este tipo de
relación es comúnmente llamada Agregación.
Asociación:
Proyecto # 1 68

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.

Representa un tipo de relación muy particular, en la que una clase es
instanciada (su instanciación es dependiente de otro objeto/clase). Se
denota por una flecha punteada.
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.
Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen
las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama
Estático de Clases o el de Casos de Uso (son diferentes).

DIAGRAMA 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.
Los casos de uso están en el interior de la caja del sistema, y los actores
fuera, y cada actor está unido a los casos de uso en los que participa
Proyecto # 1 69
Actor:
Un Actor es un rol que un usuario juega con respecto al

sistema. Un Actor no necesariamente representa a una persona en
particular, sino más bien la labor que realiza frente al sistema.
Caso 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 de otro caso de uso.
Relaciones:
1. Asociación
un actor o caso de uso a otra operación (caso de uso).
2. Dependencia o Instanciación

una clase depende de otra, es decir, se instancia (se crea).
3. Generalización

Este tipo de relación esta orientado exclusivamente para casos
de uso (y no para actores).
Proyecto # 1 70

uso.
Identificación de Casos de Uso

La identificación de casos de uso requiere un conocimiento medio acerca de
los requisitos, y se basa en la revisión de los documentos de requisitos
existentes, y en el uso de la técnica de brainstorming entre los miembros del
equipo de desarrollo.
Como guía para la identificación inicial de casos de uso hay dos métodos:
a) Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la
organización.
2. Para cada actor, identificar los procesos que inicia o en los que
participa.
b) Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a tener que
responder.
2. Relacionar los eventos con actores y casos de uso.
Proyecto # 1 71

Orientacionobjeto

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Orientacionobjeto

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE PANAMÁ

CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS

Cuando decidimos elaborar el proyecto, iniciamos analizando el

Podemos decir que un sistema de administración escolar de secundaria

En la realización de este proyecto hemos elaborado un diseño de

1. ORGANIZACIÓN Y RESULTADOS DE LA ENTREVISTA

Cal1: Registro académico del estudiante, en donde se visualizan los

1.1 Las preguntas efectuadas fueron las siguientes:

1. ¿Existe en este plantel el Proceso de Administración

2. ¿Quiénes son los encargados de llevar el Proceso de

3. ¿Cómo se lleva a cabo en este plantel el Control de

5.¿Cómo se seleccionan los estudiantes de Cuadro de Honor?

R/. Utilizando el proceso anterior Cal1, Cal2 se identifican los

6. ¿Existe, en este plantel un proceso para evaluar la eficiencia

7. ¿Cómo se calcula la estadística por salón en cuanto al

3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO

deficiencias, las estadísticas por salón, puestos de honor, y evalúe el

3.1. Definición del dominio

4. OBJETIVOS DEL SISTEMA

4.1. Objetivo general

4.2. Objetivos Específicos:

5. LISTA DE REQUISITOS DEL SISTEMA

El sistema permitirá identificar los cuadro de honor y la eficiencia

6. ANÁLISIS ORIENTADO A OBJETOS DEL SISTEMA

6.1. Identificación de las clases:

6.1.1. Clases Involucradas:

6.2. Elaboración de Glosario de Términos Procedentes del

6.3. Identificación de las Relaciones entre las clases:

Algunos estudiantes son deficientes.

6.4. Diagrama de relaciones de las clases y sus atributos:

6.5. Descripción de las clases del problema

DESCRIPCIÓN DE CADA CLASE

Estudiante * nomest: Almacena Los métodos de esta clase

Profesor * nomprof: Almacena Los métodos de esta clase

Materia * nommate: Los métodos de esta clase

Calificaciones * califica: Almacena Los métodos de esta clase

CLASES ATRIBUTOS COMPORTAMIENTO

Deficiente Esta clase contendrá el

7. IDENTIFICACIÓN DE LOS ATRIBUTOS Y PROPIEDADES DE LAS

7.1 A continuación diagrama UML de las clases

Class Class Class Class Class

8. DIAGRAMA DE CASOS DE USOS DEL SISTEMA

8.2 Como una primera aproximación identificamos a los actores

8.3 Caso de uso: Identificación de las áreas de deficiencias

¿Qué conocimientos previos fueron esenciales?

¿Qué importancia tiene para su formación profesional?

¿Qué utilidad tiene el trabajo realizado?

La utilidad que tiene este trabajo es que por el momento la mayoría de

 Los conocimientos nuevos que adquirí, a parte de entender mejor

¿Qué nuevos conocimientos se lograron?

identificar los conceptos de clases, objetos y métodos los cuales su

¿Qué conocimientos previos fueron esenciales?

¿Qué importancia tiene para su formación profesional?

¿Qué utilidad tiene el trabajo realizado?

10. REFLEXIONES FINALES

10.2 ¿Cuál fue la parte más difícil y por qué?

10.3 ¿Cuál fue la metodología para lograr los objetivos de este

11. MAPA CONCEPTUAL DE LA FASE DE ANÁLISIS TRATADA EN EL

-Documento pdf. Miguel Ángel Abian. Análisis OO.

Dirección del Mapa Conceptual

El desarrollo de este trabajo nos ha permitido ampliar nuestros

En UML, una clase es representada por un rectángulo que posee tres

 Superior: Contiene el nombre de la Clase