Proyecto 1

Análisis y Diseño con Orientación a Objetos
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 Inf._212”
“Proyecto # 1”
“Análisis y Diseño con Orientación a Objetos”
ESTUDIANTE:
BALLESTEROS, DANIEL CED. 9-704-1031

FRANCO, HERNÁN CED. 9-721-2310
ORTEGA, AMANDA CED. 9-723-367
SÁNCHEZ, AZURÍN CED. 9-721-1231
PROFESOR:
DIEGO SANTIMATEO
SEMESTRE:
II SEMESTRE – II AÑO
FECHA DE ENTREGA:
5-OCTUBRE-2007
-1-
Índice
A CONTINUACIÓN PRESENTAMOS UNA PROPUESTA UML DE UN MODELO ORIENTADO A OBJETOS, DE UN
SISTEMA DE ADMINISTRACIÓN ESCOLAR DE SECUNDARIA, ENFOCADO AL DESEMPEÑO ACADÉMICO. PARA EL
DESARROLLO DE ESTA PROPUESTA HEMOS REALIZADO CADA UNA DE LAS ETAPAS QUE INVOLUCRA LA PARTE DE
ANÁLISIS ORIENTADA A OBJETOS Y LA DOCUMENTACIÓN UML CORRESPONDIENTE. ...................................4
.....................................................................................................................................................4
EL DOCUMENTO CONTEMPLA LOS SIGUIENTES PUNTOS: OBJETIVOS DEL PROYECTO, ORGANIZACIÓN Y
RESULTADOS DE LA ENTREVISTA, UTILIDAD DE LA INFORMACIÓN, DESCRIPCIÓN DEL PROBLEMA O DOMINIO,
ANÁLISIS ORIENTADO A OBJETOS (SE DESARROLLAN LAS ETAPAS DEL ANÁLISIS OO), REFLEXIONES FINALES,
BIBLIOGRAFÍA Y WEBGRAFÍA, ALGUNOS ANEXOS. ...................................................................................4
OBJETIVOS.............................................................................................. ...........5
- OBJETIVO GENERAL DEL PROYECTO .................................................................................................5
- OBJETIVOS ESPECÍFICOS..................................................................................................................5
1. MAPA CONCEPTUAL DE LA FASE DE ANÁLISIS .................................................7
2. ORGANIZACIÓN E INFORME DE LOS DATOS RECABADOS DE LA ENTREVISTA....10
2.1. UTILIDAD DE LA INFORMACIÓN..................................................................................................13
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS ................................................................14
3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO......................................................15
3.1 DEFINICIÓN DEL DOMINIO...........................................................................................................15
4. OBJETIVOS DEL SISTEMA...............................................................................15
4.1. OBJETIVO GENERAL................................................................................................................15
4.2. OBJETIVOS ESPECÍFICOS:..........................................................................................................15
5. LISTA DE REQUISITOS DEL SISTEMA...............................................................15
6. ANÁLISIS ORIENTADO A OBJETOS .................................................................17
6.1. IDENTIFICACIÓN DE LAS CLASES DEL DOMINIO ..............................................................................18
6.2.1. Descripción de las clases del dominio: .....................................................................19
Class Puestohonor.................................................................................................................21
6.3. IDENTIFICACIÓN DE LAS RELACIONES O ASOCIACIONES ENTRE CLASES...............................................22
6.3.1. Diagrama de relación de las clases. ...........................................................................22
6.4. IDENTIFICACIÓN DE LOS ATRIBUTOS Y PROPIEDADES DE LAS CLASES..................................................23
6.4.1. Diagrama UML...........................................................................................................24
DIAGRAMA DE CASO DE USO ..........................................................................................25
7. DIAGRAMA DE CASO DE USO DEL SISTEMA.....................................................26
7.1 CASO DE USO: CONTROL DE CALIFICACIONES...............................................................................26
7.2 CASO DE USO: ESTADÍSTICAS POR SALÓN .....................................................................................27
7.3 CASO DE USO: PUESTO DE HONOR .............................................................................................28
..................................................................................................... .................28
METODOLOGÍA UTILIZADA:..............................................................................29
BIBLIOGRAFÍAS - WEBGRAFIAS.........................................................................30
ANEXOS................................................................................................. ..........31
-2-
8. REFLEXIONES FINALES ................................................................................32

REFLEXIONES INDIVIDUALES SOBRE EL TRABAJO DEL GRUPO.............................33
( AZURIM SÁNCHEZ .........................................................................................33
MODELOS......................................................................................................35
DIAGRAMAS DE ESTADO..................................................................................36
MODELADO FÍSICO DE UN SISTEMA OO...........36
Proceso de Desarrollo..........................................................................................................37
FASE DE PLANIFICACIÓN Y ESPECIFICACIÓN DE REQUISITOS...............................37
CASOS DE USO.............................................................................................37
FASE DE CONSTRUCCIÓN: DISEÑO DE BAJO NIVEL..............................................37
-3-
INTRODUCCIÓN
La programación es una actividad que requiere de esfuerzo, de ahorrar

tiempo y evitar complicaciones en muchas de las actividades que a diario
realizamos; la fase de Análisis y Diseño de Sistemas nos permite crear
sistemas más eficientes, mediante la modelación de aspectos relevantes del
dominio del problema que nos interesa resolver.
Básicamente, los resultados obtenidos durante el análisis orientado a objetos

sirven como modelo o punto de partida para realizar el diseño del sistema,
entonces podremos contar con creaciones más eficientes, que acentúen su
funcionalidad y minimicen el problema.
A continuación presentamos una propuesta UML de un modelo Orientado a

Objetos, de un Sistema de Administración Escolar de Secundaria, enfocado al
desempeño académico. Para el desarrollo de esta propuesta hemos
realizado cada una de las etapas que involucra la parte de análisis Orientada
a Objetos y la documentación UML correspondiente.
La investigación para el desarrollo de la propuesta se realizó en una escuela

secundaria de la ciudad de Santiago, provincia de Veraguas, Instituto
Profesional Omar Torrijos Herrera.
El documento contempla los siguientes puntos: Objetivos del proyecto,

organización y resultados de la entrevista, utilidad de la información,
descripción del problema o dominio, análisis Orientado a objetos (se
desarrollan las etapas del análisis OO), reflexiones finales, bibliografía y
webgrafía, algunos anexos.
-4-
OBJETIVOS
- Objetivo General del proyecto
• Desarrollar un modelo UML de información Orientado a Objetos,

basado en el enfoque de la fase de análisis de sistema, para un
Sistema de Administración Escolar de Secundaria.
- Objetivos Específicos
• Explorar y analizar información sobre la fase de análisis de

sistemas.
• Organizar entrevistas para conocer especialistas que proporcionen
información sobre el dominio donde se desarrollará el Sistema.
• Desarrollar el análisis y diseño OO basados en las distintas etapas
que le conforman.
• Diseñar modelos UML del dominio del problema basado en la
metodología de desarrollo de sistemas (POO).
-5-
MAPA CONCEPTUAL FASE DE

ANÁLISIS – (Doc. Miguel Abián)
-6-
1. Mapa conceptual de la Fase de

Análisis
Pág. 1 de 2 -7-
Pág. 2 de 2
-8-
ORGANIZACIÓN E INFORME DE LOS

DATOS RECABADOS
-9-
2. ORGANIZACIÓN E INFORME DE LOS DATOS RECABADOS DE LA

ENTREVISTA
Como parte de la primera etapa (análisis OO), hemos organizado una

entrevista con el objetivo de conocer el funcionamiento, documentos e
informes utilizados en un sistema de administración de desempeño
académico a nivel secundario. La entrevista fue realizada en el Instituto
Profesional Omar Torrijos Herrera, donde conversamos con el Director
encargado Prof. Juan Polanco, y el orientador del colegio Prof. Jesús Pino.
A continuación presentamos un informe de los datos recabados y de la

información generada, con el fin de desarrollar una propuesta UML de un
Modelo Orientado a Objeto como parte de la fase de análisis que se pretende
realizar.
Preguntas efectuadas y respuestas obtenidas:
1.-¿Quiénes son los encargados de llevar a cabo los procesos de

control de calificaciones dentro del colegio?
Resp. Cada profesor lleva el control de las calificaciones de los alumnos, luego
estas calificaciones son procesadas y archivadas por el personal de
administración.
2.- ¿Cómo se realiza el proceso de control de calificaciones?

Resp. Cada profesor presenta un informe bimestral de las calificaciones. Luego las
secretarias toman la información y realizan los confidenciales por estudiante que
incluyen calificaciones desde décimo grado hasta el año que cursan en ese
momento.
Este documento sirve como referencia para la realización de otros informes como
lo son boletines, créditos, etc.
3.-¿Cuáles documentos o informes genera y se utilizan en el

proceso de control de calificaciones?
Libreta de Documento oficial de estado que manejan los
calificaciones: educadores, en este documento se lleva el control
bimestral de calificaciones por cada estudiante.
Planillas de Son realizadas por los educadores y entregadas a la
calificaciones: administración para la confección de los confidenciales.
Los Confidenciales: Presentan la información general de cada estudiante,
desde décimo hasta el año que cursen. Este documento
sólo lo maneja la administración y se realizan
- 10 -
manualmente.
Los Boletines: Son realizados por la administración, y entregados a los
estudiantes por bimestre.
Créditos: Son documentos realizadas por la administración, y
entregados a solicitud de la parte interesada.
4.-¿Quiénes son los encargados de detectar las áreas de

deficiencia?
Resp. Profesores y coordinadores de cada asignatura.
5.-¿Cómo son detectadas las áreas de deficiencia?

Resp. Las áreas de deficiencias son detectadas por asignatura mediante dos
documentos, (CAD2 - CAD3), ambos informes se realizan bimestralmente; el
primero lo ejecuta el profesor e incluye: la matricula de estudiantes, el total de
fracasos, total de estudiantes sin calificación y retirados. Luego el Coordinador de
la asignatura recibe el CAD2 y realiza un informe final donde se registra: la
matricula total, aprobados por bimestre, fracasados por bimestre, fracasados
hasta la fecha.
6.-¿Se realizan dentro del colegio estadísticas para medir el

desempeño académico por salón?
Resp. Las estadísticas se realizan por salón identificando el bachillerato, es decir,
si existen tres grupos de bachillerato en computación se evalúa el desempeño de
los tres salones y se une como informe final.
El informe incluye: Total de Asignaturas, el total de matriculados en cada
materia, cantidad de estudiantes con deficiencia, porcentajes.
7.-¿Quiénes son los encargados realizar las estadísticas por salón?
Resp. Cada profesor entrega un informe de calificaciones bimestrales, el
consejero organiza la información con ayuda del departamento de orientación.
8. ¿Quiénes realizan los cálculos para los estudiantes cuadro de honor?

Resp. Los cálculos de los estudiantes cuadro de honor son realizados por una
comisión de profesores que nombra el director de la institución.
9. Cómo se realizan los cálculos para los estudiantes cuadro de

honor?
Resp. Para el cálculo de los estudiantes cuadro de honor los profesores utilizan
los confidenciales de cada estudiante, el mismo se calcula sumando el total de
las notas obtenidas en cada año académico entre la cantidad de materias
que tomo desde décimo hasta decimosegundo grado.
10.- ¿Se realiza una evaluación docente que muestre el desempeño

del mismo?
- 11 -
Resp. El docente realiza una autoevaluación, mediante un informe

confidencial de la labor anual.
Este informe incluye aspectos sobre la labor docente, el profesor como
agente formativo y orientador de grupos, ante sus deberes administrativos
y conducta profesional.
- 12 -
2.1. Utilidad de la Información
La información obtenida hasta el momento nos servirá como base para el

diseño de un modelo conceptual que represente los conceptos más
importantes del dominio para el que se desarrolla la propuesta UML.
Todos los datos recabados provienen de especialistas en el dominio sobre el

cual trabajaremos. Nos guiaremos en base a los conceptos y procedimientos
obtenidos para realizar un análisis detallado de un sistema de
administración escolar y elaborar los diagramas UML que la primera etapa
de análisis OO requiere.
Como parte de las siguientes etapas que se desarrollaran, utilizaremos los

resultados de ésta técnica de entrevista, para conocer requerimiento de
información que ayuden a detectar requisitos necesarios que el sistema
debe cumplir.
- 13 -
ANÁLISIS Y DISEÑO ORIENTADO A

OBJETOS
- 14 -
3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO

Se necesita en el Instituto Profesional Omar Torrijos Herrera un Sistema de
Administración Escolar de Secundaria enfocado al desempeño académico,
que logre llevar el control de calificaciones de los estudiantes del nivel de
Media, y que además permita identificar las áreas de deficiencia, estadísticas
por salón, puestos de honor y desempeño docente.
3.1 Definición del dominio

El dominio de este problema es el Instituto Profesional Omar Torrijos
Herrera, ya que representa el ámbito para el cual se desarrolla el sistema y
en el cual se realizan actividades de administración escolar del desempeño
académico
4. OBJETIVOS DEL SISTEMA
4.1. Objetivo General

• Elaborar un Sistema de Administración Escolar de Secundaria,
enfocado al desempeño académico, que logre llevar a cabo las
operaciones y procesos que actualmente lleva de forma manual el
departamento de administración del Instituto Profesional Omar Torrijos
Herrera.
4.2. Objetivos Específicos:

• Llevar el control de las calificaciones de los estudiantes de décimo a
decimosegundo grado.
• Identificar las áreas de deficiencias por materias y por salón.
• Realizar los cálculos de las calificaciones de cada estudiante con el fin
de conocer los puestos de honor.
• Determinar la eficiencia del docente en la labor pedagógica y
administrativa.
5. LISTA DE REQUISITOS DEL SISTEMA

1. Llevar a cabo un control eficiente de las calificaciones de los estudiantes
de nivel Medio, que permita identificar y gestionar notas de un año y de
un bimestre.
2. Mostrar bimestralmente cuáles son las áreas de deficiencias que presenta
el estudiante según el bachillerato que cursa.
3. Mostrar una estadística por salón que muestre la cantidad de fracasos, el
desempeño satisfactorio, estudiantes retirados, sin calificación.
- 15 -
4. Calcular los puestos de honor tomando en cuenta el historial de

calificaciones desde décimo grado hasta el grado actual que cursa.
5. Determinar la eficiencia del docente en la labor pedagógica como agente
formador y orientador de grupos, y ante sus deberes administrativos.
- 16 -
6. ANÁLISIS ORIENTADO A OBJETOS
A partir de la descripción del problema o dominio, de obtener los requisitos

del Sistema, y de consultar con expertos, utilizaremos las etapas del Análisis
Orientado a Objeto, (documento Miguel Ángel Abían), para así describir
el dominio del problema mediante clases y objetos.
ETAPAS DEL ANÁLSIS ORIENTADO A OBJETOS

Identificación de las clases de dominio
Elaboración del glosario de términos
(En este proyecto se omite el glosario ya que los
términos son conocidos)
Identificación de las Relaciones o asociaciones entre
clases
Identificación de los atributos o propiedades de las
clases
Diagrama UML
- 17 -
6.1. Identificación de las clases del dominio

Para la identificación de las Clases del dominio, utilizaremos las técnicas de
identificación de sustantivo. Extraeremos las clases de la descripción del
problema y de las entrevistas realizadas a especialistas en el dominio.
Clases del Dominio
Grupo
Class Profesor
Class
Estudiante
consejería;
nomProf;
nombre;
matricula;
código;
calificaciones;
estudiantes;
asignatura;
grado;
consejería;
prom_asignatura;
cedula;
bachillerato; );
laborDocente(
desempeñoSalon
( );
desempAcademic
laborAdministrativ
( ););
a(
historial ( );
Class Funciones
Class
Calificaciones
PuestoHonor
nombr_est;
nombre; );
captura(
cedula;
cédula;
despliega( );
grado;
calificaciones;
ordena();
calAsignatura;
materias;
suma();
promedioBimestral
puestosHonor(
promedioFinal(););
Class
Asignatura
nombreAsig;
grado;
calificaciones;
coordinador;
matricula;
areasDeficiecias(
);
totalReprob( ); - 18 -
6.2.1. Descripción de las clases del dominio:
- 19 -
Descripción del Funcionamiento de cada Clase

Clases Atributos Comportamientos
En esta clase se encuentran variables Funcionalidad del método:
de instancia privadas: desempAcademic():
nombre: nombre del estudiante. Determina el desempeño
calificaciones: se utilizan para académico tomando en
Class calcular el promedio del estudiante. cuenta las calificaciones de
Estudiante cada asignatura.
grado: grado que cursa actualmente
el estudiante. historial: archiva las
cédula: cédula del estudiante. calificaciones del estudiante
en los tres años lectivos.
bachillerato: Identifica el bachillerato
del estudiante.
Se utilizan las siguientes variables de Funcionalidad de los métodos:
instancia: laborDocente(): evaluar
nomProf: nombre del profesor. aspectos técnicos del docente,
código: Código que identifica al su desempeño, superación,
Class profesor. preparación, etc..
Profesor laborAdministrativa( ): para
asignatura: Asignatura que dicta el
profesor. considerar aspectos
administrativos
consejería: Consejería o salón del que como
está encargado. (puntualidad, entrega de
informes, datos, etc..).
Se utilizan las siguientes variables de Funcionalidad de los métodos:
instancias: totalReprob( ):calcula la
nombreAsig: indica nombre de la cantidad de estudiantes
asignatura. reprobados que existen en
grado: Grado en el que se dicta la cada asignatura para luego
asignatura. identificar las áreas de
deficiencias.
calificaciones: calificaciones de los
Class areasDeficiecias( ): en este
estudiantes en la asignatura.
Asignatura método se identifican, de
coordinador: la misma asignatura acuerdo a los valores
puede ser dictada por distintos obtenidos, las áreas de
profesores, el coordinador se deficiencias en un bimestre
encarga de recoger todas las dado.
calificaciones.
matricula: cantidad de estudiantes
en cada asignatura.
Esta clase registra los siguientes Funcionalidad de los métodos:
atributos: promedioBimestral(): Se
nombr_est: nombre del estudiante. calcula el promedio bimestral
cédula: cédula del estudiante. mediante las notas
bimestrales; para obtener el
grado: grado que cursa.
promedio final que el
Class calBimestral: Calificación de cada estudiante acumula se utiliza
Calificacio asignatura. el siguiente método:
nes promedioFinal( ): Calcula el
promedio que lleva el
estudiante en el año, obtenido
- 20 - de la suma de todas las notas
bimestrales, entre el total de
materias dadas.
Clases Atributos Comportamientos

Esta clase utiliza las siquientes Funcionalidad del método:
variables de instancia: puestosHonor( ); Es el
nombre: Nombre del estudiante método que se encarga de
cédula: Cédula del estudiante identificar cuales son los tres
Class calificaciones: Calificaciones de primeros puestos de honor;
Puestohon cada asignatura desde décimo hasta esto lo realiza sumando las
or décimo segundo grado. calificaciones de los tres años
materias: Cantidad de Materias lectivos entre el total de
que el estudiante a dado en los tres materias cursadas, se
años de bachillerato. ordenan los promedios y se
toman los tres mayores.
consejería: Es el grado o consejería. Funcionalidad del método:
matricula:Es la matricula que desempeñoSalon( ): método
mantiene el salón. que nos permite conocer el
estudiantes: nombres de los porcentaje de fracasos; para
Class estudiantes que pertenecen a un evaluar por consejería si el
Grupo grupo determinado. desempeño es excelente, bueno
o malo, accediendo a los
proml_asignatura: Calificación del promedios que mantienen los
estudiante en cada asignatura. estudiantes en cada asignatura.
Funcionalidad de los métodos:

captura( ):captura los datos o
mensajes necesarios para el
-------------- funcionamiento del sistema.
despliega( ): despliega los
Class
datos, mensajes necesarios.
Funciones
ordena(): Con este método
podemos ordenar datos del
sistema.
suma(): realiza la suma de
diferentes cantidades.
- 21 -
6.3. Identificación de las Relaciones o asociaciones entre clases

• Los estudiantes tienen asignaturas.
• Los profesores atienden diferentes grupos.
• Los profesores se encargan de una consejería.
• Los estudiantes obtienen calificaciones.
• Los profesores entregan calificaciones a la administración.
• Las calificaciones determinan el desempeño académico en cada asignatura.
• El puesto de honor se calcula a partir de las calificaciones del estudiante.
• Las calificaciones determinan el desempeño del grupo
6.3.1. Diagrama de relación de las clases.
Class
Obtien
Calificacionesnombr_
en est;
Entreg
cédula; an
grado;
calAsignatura;
Class Class
Estudiantenombre; ProfesornomProf;
calificaciones; código;
grado; asignatura;
cédula; consejería;
bachillerato;
Determina
n
Determina
n
tienen Atienden
diferentes
Se calcula Calculan
promedios
Class Asignatura
Class
nombreAsig;
Grupoconsejería;
grado;
matricula;
calificaciones; estudiantes;
coordinador; prom_asignatura;
matricula;
Class
PuestoHonornombr
e;
cédula;
calificaciones;
materias;
- 22 -
6.4. Identificación de los atributos y propiedades de las clases
En esta etapa se identifican los atributos y propiedades que tendrán las

clases, como sabemos los atributos o características de una Clase pueden
ser de tres tipos, mediante estos se define el grado de comunicación y
visibilidad de ellos con el entorno, en nuestro proyecto todos los atributos o
variables de instancia utilizadas son privadas y se identifican con la imagen
que mantienen en la parte izquierda - -
A continuación presentamos el Diagrama de Modelamiento de clases para

una mejor organización jerárquica de las clases. El mismo identifica
atributos, tipo de variables, (primitivas o de la clase String), y métodos
que le permitirán interactuar y realizar diferentes operaciones.
- 23 -
6.4.1. Diagrama UML

(Organización de las clases- incluye: Nombre de la clase, atributos y métodos)
Class Public
Class Funciones
captura( ); Sistema de
Administración
Despliega( ); Escolar
Ordena();
Suma(); Main
Class Class Asignatura Class Profesor Class Grupo Class Class

Estudiante nombreAsig: nomProf: consejeria: Calificaciones PuestoHonor
nombre: String; String; String; nombr_est: Nombre:
String; grado: String; código: String; matricula: int; String; String;
calificaciones: calificaciones: asignatura: estudiantes: cédula: String; Cédula: String;
float; String; String; grado: String; Calificaciones:
Float;
grado: String; consejería: calAsignatura: float;
coordinador:
cédula: String; String; prom_asignatura: float; Materias:int;
String; float;
bachillerato: matricula: int;
String; promedioBimest puestosHonor(
LaborDocente( ); DesempeñoSalon( ral(); );
areasDeficiecias() );
desempAcademi
c( ); ; totalReprob( ); LaborAdministrat promedioFinal( )
iva( ); ;
historial( );
- 24 -
DIAGRAMA DE CASO DE USO
- 25 -
7. Diagrama de Caso de Uso del Sistema
7.1 Caso de uso: Control de calificaciones
<<exte
Desempeño académico
<<exte
Obtiene Calificaciones <<uses
Anuales
Obtiene calificaciones
bimestrales Lleva el control de
calificaciones
Estudiante
Generar un historial
<<uses
Profesor
<<exte
Entrega nota- Bimestre
Calificaciones
<<exte
Entrega
Nota Anual
- 26 -
7.2 Caso de uso: Estadísticas por salón
<<uses
deficiencia por áreas

Estadísticas
<<uses
Desempeño
por salón <<uses
Coordinador
asignatura
Consejero
Genera promedio –
asignatura
<<uses Profesor
asignatura
Estudiante
del grupo
- 27 -
7.3 Caso de uso: Puesto de Honor
Estudiante
<<uses
Comisión
profesores
Historial de
calificaciones
<<uses
Calcula Puestos de
honor
- 28 -
METODOLOGÍA UTILIZADA:
En cuanto a la metodología utilizada mencionaremos por orden de segui-

miento cada uno de los pasos para la elaboración de la propuesta UML.
1. Se realizó un estudio de la fase de análisis tratada en el documento de Miguel Abián

(http://www.javahispano.org/tutorials.item.action?id=25
2. Se realizó un mapa conceptual sobre la fase de análisis Orientado a
Objetos, donde identificamos los conceptos más importantes al mo-
mento de realizar un Análisis Orientado a Objetos.
3. Resumen individual y en consenso de los recursos ofrecidos para esta
(WebQuest).
4. Organización y estructuración de las preguntas a realizar en el Instituto
Profesional Omar Torrijos Herrera.
5. Entrevista al Director encargado , docentes y Orientador del Instituto
Profesional Omar Torrijos Herrera los cuales nos brindan información
precisa sobre el dominio en estudio.
6. Análisis de los datos recabados en la entrevista.
7. Análisis del dominio y descripción del problema a resolver.
8. Listado de los requisitos del sistema.
9. Desarrollo de las tapa de Análisis Orientado Objetos.
10.Diagramas UML del sistema.
- 29 -
BIBLIOGRAFÍAS - WEBGRAFIAS
- Documento pdf. Miguel Angel Abian. Análisis OO.

http://www.javahispano.org/tutorials.item.action?id=25
- Desarrollo Orientado a Objetos con UML
Xavier Ferré Grau, María Isabel Sánchez Segura / Facultad de Infor-
mática – UPM
http://www.elquintero.net/Manuales/UML/umlTotal.pdf
- Herramienta para diseño de mapa conceptual
http://cmap.ihmc.us/
- Tutorial UML
http://www.clikear.com/manuales/uml/
http://www.esnips.com/doc/5ae972fd-837f-4ab4-a3c0-
e5a575567699/Tutorial-de- UML/?widget=documentIcon
- 30 -
ANEXOS
- 31 -
8. REFLEXIONES FINALES
(Amanda Ortega)
En esta primera etapa del proyecto, hemos tratado de dar la debida

importancia a la fase de Análisis Orientado a Objetos, aunque no seamos
expertos analistas el grupo se ha esforzado por consultar, explorar y analizar
distintas fuentes de información que nos permitan presentar un trabajo bien
estructurado y documentado.
En cuanto a las herramientas utilizadas, el Lenguaje de Modelamiento

Unificado (UML - Unified Modeling Language), ha sido muy práctico para
visualizar, especificar y documentar cada una de las partes que comprende
el desarrollo de software.
Luego de comentar con mis compañeros sobre la parte más difícil en el

desarrollo de esta etapa, hemos concluido en que fue la realización de los
casos de uso y la identificación de cada clase del dominio a la hora de
encapsular la información de un objeto.
El proyecto me ha permitido adquirir nuevos conocimientos en cuanto a la

importancia y esfuerzo que se debe dedicar a la fase de análisis, de igual
forma he aclarado conceptos que muchas veces se tienden a confundir en la
Programación Orientada a Objetos.
- 32 -
Reflexiones individuales sobre el trabajo del grupo

( Azurim Sánchez
1.¿ Cómo fue la labor de los integrantes?
La labor de los integrantes la considero buena, ya que los 4 nos llevamos muy bien.
Nuestro grupo se ha esforzado mucho para poder cumplir con los objetivos de este
proyecto. Considero que la labor de Amanda debe destacarse ya que fue como la
coordinadora del grupo, estuvo siempre pendiente de que todos cumplieran y entendieran lo
que se estaba haciendo.
2.¿ Cuál fue la parte más difícil y por qué?
Para mi la parte más difícil fue el análisis y diseño UML sobre todo al identificar los
componentes y establecerlos en el diagrama. Como no conocía muy bien los diagramas se
me complico esta tarea pero al leer los tutoriales ya fue un poco más fácil.
4.¿Qué nuevos conocimientos se lograron?
En lo personal me familiarice con los diagramas UML, estos a su vez me permitieron
comprender mucho mejor las relaciones entre las clases, a identificar los atributos de las
clases. Estos diagramas son muy útiles al momento de hacer programas complejos ya que
permiten establecer de manera un poco más sencilla la posible solución del problema en
cuestión.
5.¿Qué conocimientos previos fueron esenciales?
Los conocimientos previos que fueron necesarios para elaborar este proyecto fue la
Orientación a Objetos(Las clases, los objetos, etc.) que en esa parte el documento de Miguel
Abian contribuyo mucho. Al utilizar UML la OO es como un prerrequisito para poder
implementarla.
6.¿Qué importancia tiene para su formación profesional?
La importancia que tiene para mí es que al momento de solicitar un trabajo en el futuro, ya
sea en una empresa o colegio es necesario que conozca algo de UML, ya que prácticamente
es lo que esta de moda según los artículos que leí. Esto me permitirá analizar, establecer la
serie de requerimientos y estructuras necesarias para plasmar un sistema de software antes
de escribir código, para resolver cualquier problema que se presente en la empresa.
7.¿Qué utilidad tiene el trabajo realizado?
La utilidad que tiene, es que estos nuevos conocimientos (diagramas UML), me permitirán
elaborar programas con resultados de alta calidad, ya que un problema por muy complejo
que sea, El UML me ayudará haber mejor los atributos del programa y hará aparecer
relaciones entre las clases que a primera vista eran difusas o que simplemente no había
visto.
- 33 -
Reflexión individual:
(Daniel Ballesteros):
Como siempre pienso que con la dirección de la joven Amanda Ortega siempre culminamos
por lo menos para mi persona los trabajos de forma satisfactoria, cada parte del grupo
aporta elementos con los cuales logramos cumplir con los requerimientos del trabajo en
grupo; para mi persona la parte más difícil de este trabajo fue la elaboración de los
diagramas de casos de usos, es fácil ponerse a pensar lo que hacen los elementos de un
sistema desde el punto de vista de un observador externo, pero no fue tarea nada fácil
llevar esas ideas a un diagrama de casos de uso donde es más importante lo que hacen los
elementos que como lo hacen y en donde las ideas de qué forma interactúan los elementos
en un sistema deben ser transformadas en escenarios. Los conocimientos nuevos que
fueron adquiridos por mi persona fue que es importante el análisis orientado a objeto como
primera fase para crear cualquier sistema, informático o no, el tiempo que le dediquemos a
los diferentes pasos del análisis, nos permitirá tener una mejor comprensión de lo que
debemos hacer en las fases subsiguientes. Como conocimiento previo para realizar este
trabajo fue necesario leer y analizar la documentación que nos fue dada y tratar de
comprender de forma muy clara como deberíamos trabajar para lograr los objetivos del
mismo. Este trabajo que hemos realizado tiene gran importancia en nuestro desarrollo como
profesionales porque hemos aprendido a hacer un análisis orientado a objeto que es de vital
importancia para la aplicación de la programación moderna en la resolución de los
problemas que se nos propongan resolver como profesionales que aspiramos a ser.
- 34 -
Resumen Individual UML
Azurim Sánchez 9-721-1231
Entre los principales objetivos de la creación de UML esta el de posibilitar el intercambio de modelos entre las
distintas herramientas CASE orientadas a objetos del mercado.
• Modelos
Un modelo representa a un sistema software desde una perspectiva específica. Cada modelo nos permite fijarnos en
un aspecto distinto del sistema.
• Elementos Comunes a Todos los Diagramas
• Notas
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Una
nota se representa como un rectángulo con una esquina doblada con texto en su interior.
• Dependencias
La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento
destino implica un cambio en el elemento origen.
Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una
flecha en su extremo.
• Diagramas de Estructura Estática
Estos se utilizan para representar tanto Modelos Conceptuales, como Diagramas de Clases de Diseño.
Estos diagramas son distintos conceptualmente.
Clases
Las Clases se representan como una caja subdividida en tres partes en la primera el nombre de la
Clase, en la segunda los atributos y en la tercera los métodos.
Objetos
Un objeto se representa de la misma forma que una clase. En la parte superior de la caja
aparece el nombre del objeto junto con el nombre de la clase subrayada
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”.
• Diagramas de caso de uso
Este diagrama 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.
Elementos
Entre los elementos que aparecen en el diagrama casos se uso están: actores, casos de uso y
relaciones entre casos de uso.
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.
• Diagramas de Interacción
En los diagramas de interacción se muestra un patrón de interacción entre objetos, existen dos tipos
Diagramas de Secuencia y Diagramas de Colaboración.
• Diagramas de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de
eventos.
• Diagramas 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), los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos.
- 35 -
• Diagramas de Estado
Este diagrama 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 todo el sistema, en este se indican que eventos hacen que se pase de un estado a
otro y cuáles son las respuestas y acciones que genera.
• Modelado Dinámico
• Diagramas De Actividades
Estos diagramas sirven fundamentalmente para modelar el flujo de control entre actividades.
Transiciones
Las transiciones reflejan el paso de un estado a otro, ya sea actividad o de acción. Esta transición se
produce como resultado de la finalización del estado del que parte el arco dirigido que marca la transición.
El flujo debe empezar y terminar en algún momento
Bifurcaciones
Bifurcaciones quiere decir caminos alternativos, se utilizará como símbolo el rombo. Tendrá una
transición de entrada y dos o más de salida.
División y unión
Existen algunos casos que se requieren tareas concurrentes. UML representa gráficamente el proceso de
división, que representa la concurrencia, y el momento de la unión de nuevo al flujo de control secuencial,
por una línea horizontal ancha.
Modelado Físico De Un Sistema OO

o Componentes
Los componentes representan un bloque de construcción al modelar aspectos físicos de un
sistema.
Cuadro comparativo de las semejanza y diferencias entre los componentes y las clases.
SEMEJANZAS DIFERENCIAS
Ambos tienen nombre Pueden tener atributos y operaciones
directamente accesibles. Sólo tienen
operaciones y estas son alcanzables a través
de la interfaz del componente.
Ambos pueden realizar un conjunto de los componentes pueden estar en nodos y

interfaces. las clases no
o Interfaces
Los servicios propios de una clase como los de un componente, se especifican a través de una
Interfaz. Las interfaces se usan como un lazo de unión entre unos componentes y otros. La
relación se puede representar de dos maneras: de forma icónica y expandida.
o Despliegue, Nodos
Los nodos pertenecen al mundo material, un nodo 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
Cuadro comparativo de las semejanzas y diferencias de los nodos y los componentes.
SEMEJANZAS DIFERENCIAS
Ambos tienen nombre Los Nodos Los Componentes Son los elementos
donde se ejecutan los componentes.
Pueden participar en relaciones de dependencia, La relación entre un nodo y los componentes que
generalización y asociación. despliega se pueden representar mediante una
relación de dependencia
Existen dos tipos de diagramas: diagramas de Componentes y diagramas de Despliegue.
• Diagrama de Componentes
- 36 -
Este diagrama muestra la organización y las dependencias entre un conjunto de componentes.

• Diagramas de Despliegue
Arquitectura del Sistema - Arquitectura de tres niveles
Es la más común en sistemas de información que además de tener una interfaz de usuario
contemplan la persistencia de los datos.
Proceso de Desarrollo
Al construir un sistema no basta con conocer el lenguaje, es necesario que el problema sea analizado y la solución
sea cuidadosamente diseñada. El proceso de desarrollo se ocupa de plantear cómo se realiza el análisis, el diseño, y
cómo se relacionan los productos de ambos.
Fase de Planificación y Especificación de Requisitos

En esta fase se decidiría si se aborda la construcción del sistema mediante desarrollo orientado a objetos o no, por lo
que, en principio, es independiente del paradigma empleado posteriormente.
Casos de Uso
Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un
objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en
particular requisitos funcionales.
Fase de Construcción: Diseño de Alto Nivel
En esta fase de Diseño de Alto Nivel de un ciclo de desarrollo se investiga sobre el problema, sobre los
conceptos relacionados con el subconjunto de casos de uso que se esté tratando. Se pretende llegar a una
buena comprensión del problema por parte del equipo de desarrollo.
Modelo Conceptual
En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de componentes
software.
El objetivo de la creación de un Modelo Conceptual es aumentar la comprensión del problema.
• Diagramas de Secuencia del Sistema
En cada caso de uso se muestra una interacción de actores con el sistema. Los casos de uso representan una
interacción genérica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecución real
del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular.
Un Diagrama de Secuencia de Sistema se representa usando la notación para diagramas de secuencia de
UML. En él se muestra para un escenario particular de un caso de uso los eventos que los actores generan, su
orden, y los eventos que se intercambian entre sistemas.
• Diagramas de Estados
Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos: una clase software,
un concepto y un caso de uso.
Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de Estados del
sistema sería una combinación de los diagramas de todos los casos de uso. El uso de Diagramas de Estados es
opcional.
Fase de Construcción: Diseño de Bajo Nivel

En esta fase se crea una solución a nivel lógico para satisfacer los requisitos, basándose en el conocimiento reunido
en la fase de Diseño de Alto Nivel.
Modelos importantes en esta fase son el Diagrama de Clases de Diseño y los Diagramas de Interacción.
Casos de Uso Reales
Se describe el diseño real del caso de uso según una tecnología concreta de entrada y de salida y su
implementación. Como alternativa a la creación de los Casos de Uso Reales, el desarrollador puede crear
bocetos de la interfaz en papel, y dejar los detalles para la fase de implementación.
- 37 -
• Diagramas de Interacción
Ellos muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-
condiciones establecidas en un contrato
Hay dos clases de Diagramas de Interacción: diagramas de Colaboración y diagramas de Secuencia.
• Diagramas de Clase de Diseño
Este diagrama muestra la especificación para las clases software de una aplicación. Incluye la siguiente
información:
• Clases, asociaciones y atributos.
• Interfaces, con sus operaciones y constantes.
• Métodos.
Fases de Implementación y Pruebas
El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se puede probar con
los futuros usuarios, e incluso poner en producción si se ha planificado una instalación gradual.
Una vez se tiene una versión estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los
casos de uso asignados a tal ciclo.
- 38 -
- 39 -
Resumen Individual UML – Amanda Ortega

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.
MODELAMIENTO DE LAS CLASES

diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema
CLASES
Unidad básica que encapsula toda la información de un Objeto. Se representa con un rectángulo con tres posiciones:
en la parte superior contiene el nombre de la clase, en el intermedio atributos y la parte inferior los métodos. .
Atributos Pueden ser de tres tipos:
 public : Indica que el atributo será visible tanto dentro como fuera de la clase.
 private : 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.
Métodos: • 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
Forma en que se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
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 características
y atributos visibles de la Super Clase
Agregación 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 in-
cluido es independiente del que lo incluye.
Asociación La relación entre clases conocida como Asociación, permite asociar objetos que colaboran en-
tre 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 instancia-
ción es dependiente de otro objeto/clase). 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".
Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos
Clase parametri- Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en
zada donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser
instanciada
- 40 -
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
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 Obje- Se pueden visualizar llamadas a métodos desde el mismo objeto en
to: estudio.
- 41 -
DIAGRAMA DE CASOS DE USO

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:
Es el rol que el usuario juega frente al sistema.
Es importante destacar el uso de la palabra rol, pues con esto se especifi-

ca 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 invoca-
ció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 fun-
ció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 uso y no se desea
mantener copiada la descripción de la característica.
- 42 -
(Daniel Ballesteros)
Resumen Recursos Ofrecidos (UML):
En el mundo de la programación orientada a objetos existía en la dècada de

los 90's una guerra entre los diferentes mètodos que se utilizaban para
modelar un sistema OO, cada autor defendía su propuesta , hasta que un
grupo de los principales autores de estos métodos
(Principalmente Booch, OMT y OOSE), crearon con lo mejor de cada uno de
ellos un método unificado que se ha convertido en un estandar para
modelar construir y documentar los elementos de un sistema de software
OO. El UML, este método es una notación unificada para ser utilizada por los
desarrolladores OO.
Los Modelos UML:
Los modelos UML nos permiten ver diferentes perspectivas del sistema
software:
Son la disposición de un conjunto de elementos, que representan el sistema
modelado desde diferentes perspectivas. UML tiene nueve diagramas
fundamentales, agrupados en dos grandes grupos, uno para modelar la
estructura estática del sistema y otro para modelar el comportamiento
dinámico. Los diagramas estáticos son: el de clases, de objetos, de
componentes y de despliegue. Los diagramas de comportamiento son: el de
Casos de Uso, de secuencia, de colaboración, de estados y de actividades.
Muestra un conjunto de clases,

interfaces y colaboraciones, así
Clases como sus relaciones, cubriendo la
M vista de diseño estática del
O sistema.
D
E Análogo al diagrama de clases,
L muestra un conjunto de objetos y
A sus relaciones, pero a modo de
N Objetos vista instantánea de instancias de
una clase en el tiempo.
Muestra la organización y
E dependencias de un conjunto de
S Componentes componentes. Cubren la vista de
T implementación estática de un
R sistema. Un componente es un
U módulo de código, de modo que
C los diagramas de componentes
T son los análogos físicos a los
U diagramas de clases.
R Muestra la configuración del
A hardware del sistema, los nodos
de proceso y los componentes
Despliegue empleados por éstos. Cubren la
vista de despliegue estática de
una arquitectura.
- 43 -
Muestra un conjunto de casos de

uso, los actores implicados y sus
relaciones. Son diagramas
Casos de Uso fundamentales en el modelado y
organización del sistema.
Son diagramas de interacción,

M muestran un conjunto de objetos y
O sus relaciones, así como los
D mensajes que se intercambian
E Interacción entre ellos. Cubren la vista
L dinámica del sistema. El diagrama
A de secuencia resalta la ordenación
N temporal de los mensajes,
mientras que el de colaboración
resalta la organización estructural
de los objetos, ambos siendo
C equivalentes o isomorfos. En el
O diagrama de colaboración de la
M figura de la izquierda, se puede
P ver que los elementos gráficos no
O son cajas rectangulares, como
R Colaboración cabría esperar, y en su lugar
T encontramos sus versiones
A adornadas. Estas versiones tienen
M como finalidad evidenciar un rol
I específico del objeto siendo
E modelado. En la figura
N encontramos de izquierda a
T derecha y de arriba abajo un
O Actor, una Interfaz, un Control
(modela un comportamiento) y
una Instancia (modela un objeto
de dato).
Muestra una máquina de estados,
con sus estados, transiciones,
eventos y actividades. Cubren la
Estados vista dinámica de un sistema.
Modelan comportamientos
reactivos en base a eventos.
Tipo especial de diagrama de
estados que muestra el flujo de
actividades dentro de un sistema.
Actividades
En el proyecto que realizamos, pudimos observar que son tres los diagramas
(modelos) que estudiamos con detenimiento para la realización del mismo y
estos son:
Modelo de Clases:
- 44 -
• Los modelos de clases muestran un resumen del sistema en términos

de sus clases y las relaciones entre ellas. Son diagramas estáticos que
muestran qué es lo que interactúa, pero no cómo interactúa o qué
pasa cuando ocurre la interacción y está formado por los siguientes
elementos. Clase: atributos, métodos y visibilidad. Relaciones:
Herencia, Composición, Agregación, Asociación y Uso.
Modelo de Casos de usos:

• Los diagramas de Casos de Uso describen lo que hace un sistema
desde el punto de vista de un observador externo, enfatizando el qué
más que el cómo. Plantean escenarios, es decir, lo que pasa cuando
alguien interactúa con el sistema, proporcionando un resumen para
una tarea u objetivo. El siguiente Caso de Uso describe como Carlos va
a desayunar (este es su objetivo), para lo que se plantea el escenario
de preparar su café y el pan tostado
Diagrama de Casos de Uso nivel 1
• En los Casos de Uso, los Actores son papeles que determinadas

personas u objetos desempeñan. Se representan mediante un “hombre
de palitos”, de modo que en el ejemplo, Carlos es un Actor. Los Casos
de Uso se representan por medio de óvalos y las líneas que unen
Actores con Casos de Uso representan una asociación de
comunicación.
Modelo 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 responsabi-
lidades claramente.
- 45 -
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estáti-
co de Clases o el de Casos de Uso (son diferentes).
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.
- 46 -
RESUMEN DE UML
CONCENSO
A continuación presentamos un resumen de consenso sobre los recursos ofrecidos

para la documentación UML que realizamos en este proyecto.
(UML - Unified Modeling Language): El Lenguaje de Modelamiento Unificado (su
significado en español), es un lenguaje gráfico para visualizar, especificar y
documentar cada una de las partes que comprende el desarrollo de software.
En este estudio contemplamos los siguientes diagramas:
1. Modelamiento de Clases
2. Casos de Uso
3. Diagrama de Interacción
1. 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.
1.1 DIAGRAMA MODELAMIENTO DE LAS CLASES
Clases Relaciones
Es la unidad básica que encapsula toda la Forma en que se pueden interrelacionar
información de un Objeto, un objeto es una dos o más clases (cada uno con
instancia de una clase. Contiene 3 partes: características y objetivos diferentes).
Nombre de la clase, atributos o variables de
instancias, métodos u operaciones
- 47 -
Pueden ser de tres tipos:  Herencia (Especialización/Genera-

lización): Indica que una subclase he-
 public : Indica que el atributo reda los métodos y atributos especifi-
será visible tanto dentro como cados por una Super Clase.
fuera de la clase.  Agregación: Para modelar objetos
 private : sólo sus métodos lo complejos, n bastan los tipos de datos
Atribut pueden accesar. básicos que proveen los lenguajes: en-
os teros, reales y secuencias de caracte-
 protected : Indica que el atri- res.
buto no será accesible desde
fuera de la clase, pero si po-  Por valor: Es un tipo de relación
drá ser accesado por métodos estática.
de la clase además de las  Por referencia: Es un tipo de re-
subclases que se deriven. lación dinámica.
• public (): Indica que el méto-
do será visible tanto dentro  Asociación: La relación entre clases
como fuera de la clase, es de- conocida como Asociación, permite
cir, es accsesible desde todos asociar objetos que colaboran entre si.
lados.  Dependencia o Instanciación
• private (): Indica que el mé- (uso): Representa un tipo de relación
todo sólo será accesible des- muy particular, en la que una clase es
de dentro de la clase (sólo instanciada (su instanciación es de-
Método otros métodos de la clase lo pendiente de otro objeto/clase). Se de-
s pueden accesar). nota por una flecha punteada.
• protected (): Indica que el

método no será accesible des-
de fuera de la clase, pero si
podrá ser accesado por méto-
dos de la clase además de
métodos de las subclases que
se deriven (ver herencia).
2. 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.
2.1 DIAGRAMA DE CASO DE USO

Un diagrama de caso de uso consta de los siguientes elementos.
Actor: Es el rol que el usuario juega frente 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 invoca-
ción desde otro caso de uso
- 48 -
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
Rela- depende de otra, es decir, se instancia (se crea). Dicha relación se denota
ciones con una flecha punteada
Generalización
Este tipo de relación es uno de los más utilizados, cumple una doble fun-
ció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 uso y no se desea
mantener copiada la descripción de la característica.
3. 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.
3.1 DIAGRAMA DE INTERACCIÓ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 Objeto: Se representa por una flecha entre un objeto y otro, re-
presenta la llamada de un método (operación) de un objeto en particular.
Mensaje al Mismo Objeto: Se pueden visualizar llamadas a métodos desde el

mismo objeto en estudio.
- 49 -

Proyecto 1

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Proyecto 1

Загружено:

Авторское право:

Доступные форматы

Análisis y Diseño con Orientación a Objetos

“Análisis y Diseño con Orientación a Objetos”

BALLESTEROS, DANIEL CED. 9-704-1031

8. REFLEXIONES FINALES ................................................................................32

La programación es una actividad que requiere de esfuerzo, de ahorrar

Básicamente, los resultados obtenidos durante el análisis orientado a objetos

A continuación presentamos una propuesta UML de un modelo Orientado a

La investigación para el desarrollo de la propuesta se realizó en una escuela

El documento contempla los siguientes puntos: Objetivos del proyecto,

- Objetivo General del proyecto

• Desarrollar un modelo UML de información Orientado a Objetos,

• Explorar y analizar información sobre la fase de análisis de

MAPA CONCEPTUAL FASE DE

1. Mapa conceptual de la Fase de

ORGANIZACIÓN E INFORME DE LOS

2. ORGANIZACIÓN E INFORME DE LOS DATOS RECABADOS DE LA

Como parte de la primera etapa (análisis OO), hemos organizado una

A continuación presentamos un informe de los datos recabados y de la

Preguntas efectuadas y respuestas obtenidas:

1.-¿Quiénes son los encargados de llevar a cabo los procesos de

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

3.-¿Cuáles documentos o informes genera y se utilizan en el

4.-¿Quiénes son los encargados de detectar las áreas de

5.-¿Cómo son detectadas las áreas de deficiencia?

6.-¿Se realizan dentro del colegio estadísticas para medir el

8. ¿Quiénes realizan los cálculos para los estudiantes cuadro de honor?

9. Cómo se realizan los cálculos para los estudiantes cuadro de

10.- ¿Se realiza una evaluación docente que muestre el desempeño

Resp. El docente realiza una autoevaluación, mediante un informe

2.1. Utilidad de la Información

La información obtenida hasta el momento nos servirá como base para el

Todos los datos recabados provienen de especialistas en el dominio sobre el

Como parte de las siguientes etapas que se desarrollaran, utilizaremos los

ANÁLISIS Y DISEÑO ORIENTADO A

3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO

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

4. Calcular los puestos de honor tomando en cuenta el historial de

6. ANÁLISIS ORIENTADO A OBJETOS

A partir de la descripción del problema o dominio, de obtener los requisitos

ETAPAS DEL ANÁLSIS ORIENTADO A OBJETOS

6.1. Identificación de las clases del dominio

Clases del Dominio

6.2.1. Descripción de las clases del dominio:

Descripción del Funcionamiento de cada Clase

Clases Atributos Comportamientos

Funcionalidad de los métodos:

6.3. Identificación de las Relaciones o asociaciones entre clases

6.3.1. Diagrama de relación de las clases.

6.4. Identificación de los atributos y propiedades de las clases

En esta etapa se identifican los atributos y propiedades que tendrán las

A continuación presentamos el Diagrama de Modelamiento de clases para

6.4.1. Diagrama UML

Class Class Asignatura Class Profesor Class Grupo Class Class

DIAGRAMA DE CASO DE USO

7. Diagrama de Caso de Uso del Sistema

7.1 Caso de uso: Control de calificaciones

Entrega nota- Bimestre

7.2 Caso de uso: Estadísticas por salón

deficiencia por áreas