Proyecto1

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-

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

Í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

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 ANÁLISIS

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-

Análisis y Diseño con Orientación a Objetos 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-

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

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-

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

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-

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

MAPA CONCEPTUAL FASE DE ANÁLISIS – (Doc. Miguel Abián)

-6-

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

1. Mapa conceptual de la Fase de Análisis

Pág. 1 de 2

-7-

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

Pág. 2 de 2

-8-

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

ORGANIZACIÓN E INFORME DE LOS DATOS RECABADOS

-9-

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

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 educadores, en este documento se lleva el control calificaciones: bimestral de calificaciones por cada estudiante. Planillas de Son realizadas por los educadores y entregadas a la administración para la confección de los confidenciales. calificaciones: Presentan la información general de cada estudiante, Los Confidenciales: desde décimo hasta el año que cursen. Este documento sólo lo maneja la administración y se realizan

- 10 -

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

manualmente. Son realizados por la administración, y entregados a los estudiantes por bimestre. Son documentos realizadas por la administración, y entregados a solicitud de la parte interesada.

Los Boletines: Créditos: 4.-¿Quiénes deficiencia?

son

los

encargados

de

detectar

las

áreas

de

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 -

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

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 -

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

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 con Orientación a Objetos

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

- 14 -

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

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 -

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

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 -

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

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 -

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

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 Class Funciones 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 -

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

6.2.1. Descripción de las clases del dominio:

- 19 -

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

Clases

Class Estudiante

Class Profesor

Class Asignatura

Class Calificacio nes

Descripción del Funcionamiento de cada Clase Atributos Comportamientos En esta clase se encuentran variables de instancia privadas: nombre: nombre del estudiante. calificaciones: se utilizan para calcular el promedio del estudiante. grado: grado que cursa actualmente el estudiante. cédula: cédula del estudiante. bachillerato: Identifica el bachillerato del estudiante. Se utilizan las siguientes variables de instancia: nomProf: nombre del profesor. código: Código que identifica al profesor. asignatura: Asignatura que dicta el profesor. consejería: Consejería o salón del que está encargado.

Funcionalidad del método:

nombreAsig: indica nombre de la asignatura. grado: Grado en el que se dicta la asignatura. calificaciones: calificaciones de los estudiantes en la asignatura. coordinador: la misma asignatura puede ser dictada por distintos profesores, el coordinador se encarga de recoger todas las calificaciones. matricula: cantidad de estudiantes en cada asignatura.

cantidad de estudiantes reprobados que existen en cada asignatura para luego identificar las áreas de deficiencias.

Esta clase registra los siguientes atributos: nombr_est: nombre del estudiante. cédula: cédula del estudiante. grado: grado que cursa. calBimestral: Calificación de cada asignatura.

Funcionalidad de los métodos:

desempAcademic(): Determina el desempeño académico tomando en cuenta las calificaciones de cada asignatura. historial: archiva las calificaciones del estudiante en los tres años lectivos. Funcionalidad de los métodos: laborDocente(): evaluar aspectos técnicos del docente, su desempeño, superación, preparación, etc..

laborAdministrativa( ): para considerar aspectos administrativos como (puntualidad, entrega de informes, datos, etc..). Se utilizan las siguientes variables de Funcionalidad de los métodos: instancias: totalReprob( ):calcula la

- 20 -

areasDeficiecias( ): en este método se identifican, de acuerdo a los valores obtenidos, las áreas de deficiencias en un bimestre dado.

promedioBimestral(): Se calcula el promedio bimestral mediante las notas bimestrales; para obtener el promedio final que el estudiante acumula se utiliza el siguiente método: promedioFinal( ): Calcula el promedio que lleva el estudiante en el año, obtenido de la suma de todas las notas bimestrales, entre el total de materias dadas.

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

Clases

Class Puestohon or

Class Grupo

Atributos Esta clase utiliza las siquientes variables de instancia: nombre: Nombre del estudiante cédula: Cédula del estudiante calificaciones: Calificaciones de cada asignatura desde décimo hasta décimo segundo grado. materias: Cantidad de Materias que el estudiante a dado en los tres años de bachillerato. consejería: Es el grado o consejería. matricula:Es la matricula que mantiene el salón. estudiantes: nombres de los estudiantes que pertenecen a un grupo determinado. proml_asignatura: Calificación del estudiante en cada asignatura.

Comportamientos Funcionalidad del método: puestosHonor( ); Es el método que se encarga de identificar cuales son los tres primeros puestos de honor; esto lo realiza sumando las calificaciones de los tres años lectivos entre el total de materias cursadas, se ordenan los promedios y se toman los tres mayores. Funcionalidad del método: desempeñoSalon( ): método que nos permite conocer el porcentaje de fracasos; para evaluar por consejería si el desempeño es excelente, bueno o malo, accediendo a los promedios que mantienen los estudiantes en cada asignatura. Funcionalidad de los métodos:

--------------

captura( ):captura los datos o mensajes necesarios para el funcionamiento del sistema. despliega( ): despliega los datos, mensajes necesarios.

Class Funciones

ordena(): Con este método podemos ordenar datos del sistema. suma(): realiza la suma de diferentes cantidades.

- 21 -

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

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.

Obtien en

Class Calificacionesnombr_ est; cédula; grado; calAsignatura;

Entreg an

Class Estudiantenombre; calificaciones; grado; cédula; bachillerato;

Class ProfesornomProf; código; asignatura; consejería; Determina n

Determina n tienen

Atienden diferentes Se calcula

Class

Calculan promedios

Asignatura

Class Grupoconsejería; matricula; estudiantes; prom_asignatura;

nombreAsig; grado; calificaciones; coordinador; matricula; Class PuestoHonornombr e; cédula; calificaciones; materias;

- 22 -

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

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 -

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

6.4.1. Diagrama UML (Organización de las clases- incluye: Nombre de la clase, atributos y métodos)

Class Public

Class Funciones

Sistema de Administración Escolar

captura( ); Despliega( ); Ordena();

Main

Suma();

Class Estudiante nombre: String; calificaciones: float; grado: String; cédula: String; bachillerato: String; desempAcademi c( ); historial( );

Class Asignatura

nombreAsig: String; grado: String; calificaciones: Float; coordinador: String; matricula: int; areasDeficiecias() ;

totalReprob( );

Class Profesor nomProf: String; código: String; asignatura: String; consejería: String;

Class Grupo consejeria: String; matricula: int; estudiantes: String;

LaborDocente( );

DesempeñoSalon( );

LaborAdministrat iva( );

- 24 -

prom_asignatura: float;

Class Calificaciones nombr_est: String; cédula: String; grado: String; calAsignatura: float;

Class PuestoHonor Nombre: String; Cédula: String; Calificaciones: float; Materias:int;

promedioBimest ral();

);

promedioFinal( ) ;

puestosHonor(

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

DIAGRAMA DE CASO DE USO

- 25 -

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

7. Diagrama de Caso de Uso del Sistema 7.1 Caso de uso: Control de calificaciones

<<exte Desempeño académico

<<exte Obtiene Calificaciones Anuales

<<uses

Obtiene calificaciones bimestrales

Lleva el control de calificaciones

Estudiante Generar un historial

<<uses

Profesor

<<exte

Entrega nota- Bimestre Calificaciones

<<exte Entrega Nota Anual

- 26 -

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

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

Obtiene calificaciones

Estudiante del grupo

- 27 -

Profesor asignatura

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

7.3 Caso de uso: Puesto de Honor

Obtiene calificaciones Estudiante

<<uses

Comisión profesores Historial de calificaciones

<<uses

Calcula Puestos de honor

- 28 -

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

METODOLOGÍA UTILIZADA: En cuanto a la metodología utilizada mencionaremos por orden de seguimiento 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 momento 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 -

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

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 Informá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-a3c0e5a575567699/Tutorial-deUML/?widget=documentIcon -

- 30 -

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

ANEXOS

- 31 -

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

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 -

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

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 -

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

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 -

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

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 -

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

•

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 Ambos tienen nombre

DIFERENCIAS 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 -

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

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 -

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

•

Diagramas de Interacción

Ellos muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las postcondiciones 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 -

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

- 39 -

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

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:

Métodos:

 

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. 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 incluido es independiente del que lo incluye. Asociación

Dependencia

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. Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciació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 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

- 40 -

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

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 Objeto:

Se pueden visualizar llamadas a métodos desde el mismo objeto en estudio.

- 41 -

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

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 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 uso y no se desea mantener copiada la descripción de la característica.

- 42 -

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

(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í como sus relaciones, cubriendo la vista de diseño estática del sistema.

Clases M O D E L A N E S T R U C T U R A

Análogo al diagrama de clases, muestra un conjunto de objetos y sus relaciones, pero a modo de vista instantánea de instancias de una clase en el tiempo. Muestra la organización y dependencias de un conjunto de componentes. Cubren la vista de implementación estática de un sistema. Un componente es un módulo de código, de modo que los diagramas de componentes son los análogos físicos a los diagramas de clases. Muestra la configuración del hardware del sistema, los nodos de proceso y los componentes empleados por éstos. Cubren la vista de despliegue estática de una arquitectura.

Objetos

Componentes

Despliegue

- 43 -

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

Muestra un conjunto de casos de uso, los actores implicados y sus relaciones. Son diagramas fundamentales en el modelado y organización del sistema.

Casos de Uso

M O D E L A N

C O M P O R T A M I E N T O

Son diagramas de interacción, muestran un conjunto de objetos y sus relaciones, así como los mensajes que se intercambian entre ellos. Cubren la vista dinámica del sistema. El diagrama de secuencia resalta la ordenación temporal de los mensajes, mientras que el de colaboración resalta la organización estructural de los objetos, ambos siendo equivalentes o isomorfos. En el diagrama de colaboración de la figura de la izquierda, se puede ver que los elementos gráficos no son cajas rectangulares, como cabría esperar, y en su lugar encontramos sus versiones adornadas. Estas versiones tienen como finalidad evidenciar un rol específico del objeto siendo modelado. En la figura encontramos de izquierda a derecha y de arriba abajo un 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 vista dinámica de un sistema. Modelan comportamientos reactivos en base a eventos.

Interacción

Colaboración

Estados

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 -

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

•

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 responsabilidades claramente.

- 45 -

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

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático 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 -

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

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 -

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

Pueden ser de tres tipos: 

Atribut os





•

•

Método s •



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. 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).

Herencia (Especialización/Generalización): Indica que una subclase hereda los métodos y atributos especificados por una Super Clase. Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres.  Por valor: Es un tipo de relación

estática.  Por referencia: Es un tipo de re-

lación dinámica. Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. 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.

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).

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 invocación desde otro caso de uso

- 48 -

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

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

Relaciones

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 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, representa 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 -