UNIVERSIDAD DE PANAMÁ CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS FACULTAD DE INFORMÁTICA ELECTRÓNICA Y COMUNICACIÓN LICENCIATURA EN INFORMÁTICA PARA LA GESTIÓN EDUCATIVA

Y EMPRESARIAL PROGRAMACIÓN IV TEMA DISEÑO Y ANÁLISIS ORIENTADO A OBJETO FACILITADOR DIEGO SANTIMATEO ELABORADO POR CALLES YORISBETH GONZÁLEZ ROMAN GONZÁLEZ FÁTIMA MANZANÉ ANNETH II AÑO II SEMESTRE FECHA DE ENTREGA 5 DE OCTUBRE DE 2007 9-720-2373 9-705-1420 9-721-2074 9-719-2292

ÍNDICE

Introducción.....................................................................................................1 CONTENIDO.....................................................................................................1 1.ORGANIZACIÓN Y RESULTADOS DE LA ENTREVISTA.....................................1 1.1 Las preguntas efectuadas fueron las siguientes:...................................................................1 2. UTILIDAD DE LA INFORMACIÓN....................................................................3 3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO...................................................3 3.1. Definición del dominio.........................................................................................................4 4. OBJETIVOS DEL SISTEMA..............................................................................4 4.1. Objetivo general....................................................................................................................4 4.2. Objetivos Específicos:..........................................................................................................4 5. LISTA DE REQUISITOS DEL SISTEMA............................................................4 6. ANÁLISIS ORIENTADO A OBJETOS DEL SISTEMA .......................................5 6.1. Identificación de las clases:..................................................................................................5 6.1.1. Clases Involucradas:......................................................................................................5 6.2. Elaboración de Glosario de Términos Procedentes del Dominio:........................................5 6.3. Identificación de las Relaciones entre las clases:.................................................................5 6.4. Diagrama de relaciones de las clases y sus atributos:...........................................................7 6.5. Descripción de las clases del problema................................................................................7 7. IDENTIFICACIÓN DE LOS ATRIBUTOS Y PROPIEDADES DE LAS CLASES......10 7.1 A continuación diagrama UML de las clases.......................................................................11 8. DIAGRAMA DE CASOS DE USOS DEL SISTEMA..........................................12 8.2 Como una primera aproximación identificamos a los actores que interactúan con el sistema:......................................................................................................................................12 ...........................................................................................................................................12 8.3 Caso de uso: Identificación de las áreas de deficiencias.....................................................13 9. COEVALUACIÓN..........................................................................................15 10. REFLEXIONES FINALES.............................................................................18 11. MAPA CONCEPTUAL DE LA FASE DE ANÁLISIS TRATADA EN EL DODUMENTO DE MIGUEL ÁNGEL ABIÁN........................................................19 WEBGRAFIAS..................................................................................................22 CONCLUSIÓN..................................................................................................23 ANEXO............................................................................................................25 RESUMEN INDIVIDULES..................................................................................26 CONSENSO.....................................................................................................66

INTRODUCCIÓN

Cuando decidimos elaborar el proyecto, iniciamos analizando el enunciado, estableciendo el objetivo que queremos alcanzar, luego pasamos a desarrollar los pasos sugeridos del proyecto, que nos permitió desarrollar un modelo UML de información sobre un sistema de administración escolar secundario, basado en el enfoque orientado a objeto. Podemos decir que un sistema de administración escolar de secundaria enfocado al desempeño académico, que además de llevar a cabo el control de calificaciones, es capaz de identificar las áreas de deficiencias , las estadísticas por salón, los puestos de honor y la eficiencia docente. En la realización de este proyecto hemos elaborado un diseño de sistema de administración escolar de secundaria que contiene las fases de análisis y diseño de una programación orientada a objeto que a continuación presentaremos:

Análisis y Diseño con Orientación a Objeto CONTENIDO 1. ORGANIZACIÓN Y RESULTADOS DE LA ENTREVISTA Para realizar esta primera etapa (análisis OO), la cual tiene el objetivo de una propuesta UML del funcionamiento de un sistema de administración escolar de secundaria enfocado al desempeño académico, escogimos para ello, el Instituto Profesional y Técnico de Veraguas (IPTV), ubicado en el distrito de Santiago corregimiento de Canto del Llano. Para llevar a cabo la Entrevista acudimos a dicho Centro, en el mismo fuimos atendidos por el Sub-Director del plantel, el cual dio respuesta a todas nuestras preguntas. Observación: Cal1: Registro académico del estudiante, en donde se visualizan los estudiantes Aprobados y Fracasados en el bimestre, Fracasados a la Fecha, sin Calificación y los Retirados. El mismo es revisado por el coordinador. Cal2: Contiene un informe mas preciso y detallado del rendimiento de cada estudiante; el mismo se deriva del Cal1 después de su previa revisión por parte del coordinador.

1.1 Las preguntas efectuadas fueron las siguientes: 1. ¿Existe en este plantel el Proceso de Administración Escolar? R/. En el plantel se da un proceso de Administración Escolar, pero de manera manual porque el sistema educativo no permite llevar a cabo un control automatizado.

Proyecto # 1

1

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

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

Proyecto # 1

2

Análisis y Diseño con Orientación a Objeto R/. Utilizando el proceso anterior Cal1, Cal2 se identifican los estudiantes de cuadro de honor; generalmente el promedio es de 4.5 en adelante. 6. ¿Existe, en este plantel un proceso para evaluar la eficiencia docente? R/. En este plantel no existe un proceso para evaluar la eficiencia docente. 7. ¿Cómo se calcula la estadística por salón en cuanto al desempeño académico del estudiante? R/. Mediante el Cal1 entregado por cada profesor se calcula la estadística estudiante. 2. UTILIDAD DE LA INFORMACIÓN Es de mucha importancia todos estos datos recabados de la entrevista realizada al Sub-Director encargado de este centro educativo, para poder realizar un análisis detallado de un sistema de administración escolar y confeccionar los respectivos diagramas UML que esta primera etapa (análisis OO) requiere. Por lo tanto es de gran utilidad, conocer los requisitos necesarios que debe cumplir un sistema para satisfacer las necesidades de los usuarios, reflejando así que debe hacer el sistema, y poder realizar un análisis OO detallado, con sus respectivos diagramas UML. 3. DESCRIPCIÓN DEL PROBLEMA O DOMINIO En el Instituto Profesional y Técnico de Veraguas (IPTV) se necesita un sistema informático en el área de administración escolar que gestione todo lo relacionado al desempeño académico tanto de alumnos como docentes que lleve el control de las calificaciones, identifique las áreas de por salón en cuanto al desempeño académico del

Proyecto # 1

3

Análisis y Diseño con Orientación a Objeto deficiencias, las estadísticas por salón, puestos de honor, y evalúe el desempeño eficiente de los docentes. 3.1. Definición del dominio El dominio del problema esta basado en el enfoque orientado a objeto de un sistema de Administración Escolar de Secundaria para atender diversas necesidades que pueden presentar un centro educativo; basándonos en este dominio se clasificaron las clases utilizadas.

4. OBJETIVOS DEL SISTEMA 4.1. Objetivo general Analizar y Diseñar un sistema de Administración Escolar enfocado al desempeño académico utilizando Orientación a Objetos y representación UML.

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

Proyecto # 1

4

Análisis y Diseño con Orientación a Objeto El sistema permitirá identificar los cuadro de honor y la eficiencia de los docentes.  Mostrar la estadística por salón en cuanto a la cantidad de fracaso y el desempeño satisfactorio de los estudiantes. 6. ANÁLISIS ORIENTADO A OBJETOS DEL SISTEMA 6.1. Identificación de las clases: Para identificar las clases del dominio del problema utilizamos las técnicas descritas en el documento de Miguel Ángel Abian. 6.1.1. Clases Involucradas: Estudiante

Profesor Clases Deficiente

Materia

Calificaciones

Cuadro de Honor

6.2. Elaboración de Glosario de Términos Procedentes del Dominio: Esta etapa la omitimos, ya que sus términos son de uso común, ya que se describen dentro de dicho proyecto. 6.3. Identificación de las Relaciones entre las clases: Los estudiantes necesitan de las materias Los estudiantes necesitan de los profesores Los estudiantes tienen calificaciones. El cuadro de honor necesita de las calificaciones. Proyecto # 1 5

Análisis y Diseño con Orientación a Objeto Algunos estudiantes son deficientes. Los profesores entregan calificaciones.

Proyecto # 1

6

Análisis y Diseño con Orientación a Objeto 6.4. Diagrama de relaciones de las clases y sus atributos:

Clase Estudiante
Nombre Grado

Necesita

Necesitan

Nombre Materia Cant. de estudiante Calificaciones del estudiante.

Clase Profesor

Alguno s son Tiene

Nombre Nombre del Profesor Nivel Académico

Clase Materia

Clase Deficiente
Nombre de la

Calificaciones Nombre del Estudiante

Clase Cuadro de Honor

Entreg an Clase Calificaciones
Calificaciones Grado

Necesit

6.5. Descripción de las clases del problema Luego de haber abstraído las clases que formarán nuestro sistema, se detallará a continuación el funcionamiento de las mismas con sus atributos o variables de instancia.

Proyecto # 1

7

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

CLASES Principal

DESCRIPCIÓN DE CADA CLASE ATRIBUTOS COMPORTAMIENTO El método de esta clase es el Main en el cual se llama a las otras clases las mismas son las siguientes: * * * * * * Class Class Class Class Class Class Estudiante Profesor Materia Calificaciones CuadrodeHonor Deficientes

Estudiante

* nomest: Almacena el Nombre del estudiante. * grado: Almacena el nivel que cursa el estudiante. * calificaciones: Almacena las calificaciones de los estudiantes. * nomprof: Almacena el nombre del profesor. * cantestu: Almacena la cantidad de estudiantes. * mate: Almacena la materia que imparte el profesor. * nommate: Almacena el nombre de la materia. * nomprofmate: Almacena el nombre del profesor que dicta la materia.

Los métodos de esta clase serian los siguientes: * getNombre(): el cual devolverá el nombre del estudiante. * getGrado(): el cual devolverá el grado que cursa el estudiante.

Profesor

Los métodos de esta clase serian los siguientes: * getProf(): el cual devuelve el nombre del profesor. * getRep(): el cual devuelve la cantidad de estudiantes reprobados. * getApro(): el cual devuelve la cantidad de aprobados. Los métodos de esta clase serian los siguientes: * getMate(): el cual devolverá el nombre de la materia. * getProfmate(): el cual devolverá el nombre del profesor que dicta esa materia. 8

Materia

Proyecto # 1

Análisis y Diseño con Orientación a Objeto Calificaciones * califica: Almacena las calificaciones del estudiante. * nombestu: Almacena el nombre del estudiante. Los métodos de esta clase serian los siguientes: * promBime(): este método calculará el promedio bimestral de las calificaciones obtenidas en cada asignatura. * promFin(): calculará el promedio que llevará el estudiante en el año,obtenida a partir del método anterior. COMPORTAMIENTO Esta clase contendrá el siguiente método: * mayProm (): este método se encarga de obtener los estudiantes de cuadro de honor. Esta clase contendrá el siguiente método: * cantDefmat (): este método se encarga de obtener la cantidad de estudiantes deficientes de una determinada materia.

CLASES Cuadro de Honor

ATRIBUTOS * calif: Almacena las calificaciones del estudiante. * nombest: Almacena el nombre del estudiante. “No contiene variables de instancia”

Deficiente

Proyecto # 1

9

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

7. IDENTIFICACIÓN DE LOS ATRIBUTOS Y PROPIEDADES DE LAS CLASES En esta etapa procedemos a identificar los atributos y propiedades que conforman el sistema mediante el Diagrama UML.

Proyecto # 1

10

Análisis y Diseño con Orientación a Objeto 7.1 A continuación diagrama UML de las clases

Class Principal

main()

Class Estudiante
* String nomest * String grado * float * getNombre() * getGrado()

Class Profesor
* String nomprof * int cantestu * String mate * getProf() * getRep() * getApro()

Class Materia
* String nommate * String * getMate() * getProfmate()

Class Calificaciones
* float califica * String nombestu * promBime() * promFin()

Class Cuadro de Honor * float calif
* String nomest * mayProm ()

Class Deficiencia

* ()

cantDefmat

Proyecto # 1

11

Análisis y Diseño con Orientación a Objeto 8. DIAGRAMA DE CASOS DE USOS DEL SISTEMA 8.1 Definición de Diagrama de Caso de Uso Es una tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. En todo análisis OO, es necesario diseñar diagramas de usos que nos ayudan a desarrollar y visualizar un sistema.

8.2 Como una primera aproximación identificamos a los actores que interactúan con el sistema:

Coordinador

Profesor

Identificar áreas de deficiencias

Comisión de Rendimiento

Orientación

Proyecto # 1

12

Análisis y Diseño con Orientación a Objeto 8.3 Caso de uso: Identificación de las áreas de deficiencias

Entrega Cal1

Profesor Coordinad or revisa Cal1 Genera reporte (Cal2) Reporte de deficien cia

Comisió n de rendimie nto académi Orientación Recibe información de rendimiento

Dirección Recibe información de rendimiento

Proyecto # 1

13

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

Proyecto # 1

14

Análisis y Diseño con Orientación a Objeto 9. COEVALUACIÓN YORISBETH CALLES Para la elaboración de este proyecto obtuve nuevos conocimiento en cuanto a un Análisis y Diseño de Orientado a Objeto, la confección de diagramas UML, aclare dudas sobre los conceptos de clases, objeto, métodos, ya que necesitaba de ellos para poder continuar con el proyecto como trabaja con un dominio. Este proyecto es de mucha importancia, por que para ser una buena programadora tendré presente antes de programar, analizar primero el dominio y después programar. ROMAN GONZÁLEZ ¿Qué conocimientos previos fueron esenciales? Los conocimientos previos que fueron esenciales fueron los de tener una base en programación c++ para tener o hacer una relación con funciones de c++ y métodos en java. Los conocimientos adquiridos al leer los documentos o recursos brindados para este proyecto. conceptos previos como clases, métodos, objetos; que a la vez se fueron reforzando en la elaboración de este trabajo. Tener una idea de como se lleva el control de calificaciones de una escuela. ¿Qué importancia tiene para su formación profesional? La importancia que tiene es que nos a enseñado a analizar mas. De esta forma cuando se nos presente un problema, no empezaremos a resolverlo sin antes analizarlo y buscar la forma correcta de resolverlo. ¿Qué utilidad tiene el trabajo realizado?

Proyecto # 1

15

Análisis y Diseño con Orientación a Objeto La utilidad que tiene este trabajo es que por el momento la mayoría de las escuelas llevan un control de rendimiento académico de forma manual, porque así el ministerio se los exige, y cuando llegue el momento en que las escuelas empiecen a implementar un control mas sistematizado, cuenten con una base para resolver este problema, que podría ser uno de nuestros análisis. ANNETH MANZANÉ

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

FÁTIMA GONZÁLEZ ¿Qué nuevos conocimientos se lograron? Después de la elaboración del proyecto he adquirido nuevos conocimientos como la elaboración de los diagramas UML, así como Proyecto # 1 16

Análisis y Diseño con Orientación a Objeto identificar los conceptos de clases, objetos y métodos los cuales su definición al inicio eran un poco confusas, hoy día estos términos han sido aclarados permitiéndome un mayor entendimiento sobre la programación orientada a objetos. ¿Qué conocimientos previos fueron esenciales? Manejar los conceptos de programación orientada a objeto bajo la plataforma de java, que las clases en java es un conjunto de variables y métodos encapsulados que realizan una tarea especifica, los objetos es una variable que puede ser referencia a un método de una clase y los métodos agrupan pasos y procesos para resolver una tarea en especial, estos son algunos de los conocimientos previos que fueron esenciales y de mucha utilidad para la elaboración de este proyecto.

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

¿Qué utilidad tiene el trabajo realizado? Es de mucha utilidad porque me da las bases para desarrollar mis futuras aplicaciones, permitiendo manejar los conceptos de la programación estructurada en java.

Proyecto # 1

17

Análisis y Diseño con Orientación a Objeto 10. REFLEXIONES FINALES 10.1 ¿Cómo fue la labor de los integrantes? Después de haber leído los aspectos que abarcarían el proyecto, sus puntos a evaluar y visitados los recursos ofrecidos por parte del facilitador del curso, los integrantes del grupo colaboraron de manera organizada y aportaron sus ideas sobre la fase de análisis tratada en el documento de Miguel Ángel Abían, las cuales fueron muy acogidas por todos los integrantes del grupo. A partir de allí y llevando paso a paso cada punto a desarrollar, se llevo a cabo la elaboración del proyecto que hoy le presentamos, esperando sea lo solicitado. 10.2 ¿Cuál fue la parte más difícil y por qué? A continuación le describimos los puntos que fueron más difíciles: Uno de ellos fue la elaboración del Diagrama de Caso de Uso; allí se nos presento dificultad ya que no teníamos un conocimiento previo de su confección y utilidad. Se nos hizo difícil encontrar las clases involucradas, ya que momentos en que pensábamos que había teníamos todas las clases del

problema, pero de pronto surgían otras ideas, las cuales nos llevaban a involucrar otras clases, y teníamos que reestructurar nuestra solución. Otro de los puntos que se nos hizo un poco difícil fue las descripciones de las clases, esto se dio porque no teníamos una idea clara de lo que en realidad el sistema tenía como objetivo. “Pero como en la vida nada es inalcanzable y querer es poder se logro sacar hacia delante estos puntos, no de manera eficaz pero consideramos que muy eficientes, todo esto se realizo con la colaboración de todos los integrantes” 10.3 ¿Cuál fue la metodología para lograr los objetivos de este trabajo?

Proyecto # 1

18

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

Proyecto # 1

19

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

Proyecto # 1

20

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

Proyecto # 1

21

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

-Documento pdf. Miguel Ángel Abian. Análisis OO. http://www.javahispano.org/tutorials.item.action?id=25 -Herramienta para diseño de mapa conceptual http://cmap.ihmc.us/ -Tutorial UML recomendado para la captación rápida de los conceptos y aplicación de esta tecnología:

http://www.clikear.com/manuales/uml/ http://www.esnips.com/doc/5ae972fd-837f-4ab4-a3c0e5a575567699/Tutorial-de-UML/?widget=documentlcon

Dirección del Mapa Conceptual

http://es.geocities.com/orientacionobjeto/analisis.html

Proyecto # 1

22

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

CONCLUSIÓN

El

desarrollo

de

este

trabajo

nos

ha

permitido

ampliar

nuestros

conocimientos acerca de la programación orientada dominio del lenguaje Java.

a objetos bajo el

Familiarizarse con la estructura de un programa en Java facilita el desarrollo de aplicaciones para automatizar los sistemas en general ya que permite, analizar y diseñar soluciones para los problemas y necesidades de nuestra vida diaria con una visión cercana a la realidad sin contar que la reutilización de clases y métodos en Java le facilita el trabajo al programador.

Proyecto # 1

23

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

Proyecto # 1

24

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

ANEXO

Proyecto # 1

25

Análisis y Diseño con Orientación a Objeto RESUMEN INDIVIDULES YORISBTEH CALLES Diagrama UML El Lenguaje de Modelamiento Unificado (Uml). Es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. El documento contempla el estudio de tres diagramas:
  

Modelamiento de Clases Casos de Uso Diagrama de Interacción

Modelos de clase: Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema. Un diagrama de clases esta compuesto por los siguientes elementos:
 

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos: Clase: Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). En UML, una clase es representada por un rectángulo que posee tres divisiones:
 

Superior: Contiene el nombre de la Clase Intermedio: Clase public). Contiene ser los atributos protected métodos (o o u variables de instancia) que caracterizan a la (pueden private, los

Inferior:

Contiene

operaciones, los cuales son la forma como interactúa el objeto

Proyecto # 1

26

Análisis y Diseño con Orientación a Objeto con su entorno (dependiendo de la visibilidad: private, protected o public). Atributos: Los atributos o características de una Clase pueden ser de tres tipos.

public (+,

): Indica que el atributo será visible tanto dentro

como fuera de la clase, es decir, es accsesible desde todos lados.

private (-,

): Indica que el atributo sólo será accesible desde

dentro de la clase (sólo sus métodos lo pueden accesar).

protected (#,

): Indica que el atributo no será accesible

desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia). Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características.

public (+,

): Indica que el método será visible tanto dentro

como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, accesar).

): Indica que el método sólo será accesible desde

dentro de la clase (sólo otros métodos de la clase lo pueden

protected (#,

): Indica que el método no será accesible

desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). Relaciones entre Clases:

Proyecto # 1

27

Análisis y Diseño con Orientación a Objeto Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
  

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected)

Agregación:

Para modelar objetos complejos, n bastan los tipos de datos básicos reales se que y proveen secuencias los de lenguajes: caracteres. enteros, Cuando

requiere

componer

objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: por valor, por referencia.

Proyecto # 1

La composició n (por Valor) se destaca

La agregación (por Referencia) se

28

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

Asociación: relación entre permite clases asociar conocida objetos como que

La

Asociación,

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

Dependencia o Instanciación (uso): un tipo de relación muy

Representa

particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada. Casos de Uso (Use Case) El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:
  

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.

Elementos

Actor: Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es

Proyecto # 1

29

Análisis y Diseño con Orientación a Objeto importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Caso de Uso: Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. Relaciones: Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de

Proyecto # 1

30

Análisis y Diseño con Orientación a Objeto uso y no se desea mantener copiada la descripción de la característica. Ejemplo de una diagrama de uso:

Proyecto # 1

31

Análisis y Diseño con Orientación a Objeto Diagrama de Interacción El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Los componentes de un diágrama de interacción son:
  

Un Objeto o Actor. Mensaje de un objeto a otro objeto. Mensaje de un objeto a si mismo.

Elementos

Objeto/Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

Proyecto # 1

32

Análisis y Diseño con Orientación a Objeto Ejemplo de modelo estático:

Proyecto # 1

33

Análisis y Diseño con Orientación a Objeto ROMAN GONZÁLEZ TUTORIAL UML UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables. Modelo de clases : Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema. Un diagrama de clases esta compuesto por los siguientes elementos: Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Objeto: un objeto es una instancia de una clase. Encapsulamiento: El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. Abstracción: La abstracción consiste en captar las características

esenciales de un objeto, así como su comportamiento. Entornos que pueden ser de estudios para crear una clase : una Casa, un Auto, una Cuenta Corriente, etc.

Definición de una clase: Es la unidad básica que encapsula toda la información de un Objeto. A través de ella podemos modelar el entorno en estudio. Una clase es una agrupación de datos (variables ) y de funciones que operan sobre esos datos (metodos). En UML, una clase es representada por un rectángulo que posee tres divisiones: Proyecto # 1 34

Análisis y Diseño con Orientación a Objeto Nombre clase Atributos Operaciones o métodos
 

Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Atributos y Métodos:

Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno. Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno. Tipos de atributos y métodos

Proyecto # 1

35

Análisis y Diseño con Orientación a Objeto Tipos public (+, Atribut os protected ) ) Descripcion Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es Indica quedesde todos lados. será accesible accsesible el atributo sólo desde dentro de la clase (sólo sus métodos

private (-,

)

(#, lo pueden accesar). Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia). Indica que el método será visible tanto dentro como fuera de la clase, es decir, es ) accsesible desde todos lados. será accesible Indica que el método sólo desde dentro de la clase (sólo otros

public (+,

)

Método s

private (-, protected )

(#, métodos de la clase lo pueden acceder). Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre Clases: Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). Cardinalidad: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
 

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n)

Proyecto # 1

36

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

número fijo: m (m denota el número). Herencia (Especialización/Generalización): Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected). Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: 1. Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). 2. Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento). En donde se destaca que: 3. Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Proyecto # 1

37

Análisis y Diseño con Orientación a Objeto 4. Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. 5. La composición (por Valor) se destaca por un rombo relleno. 6. La agregación (por Referencia) se destaca por un rombo transparente. La flecha en este tipo de relación indica la navegabilidad del objeto refereniado. Cuando no existe este tipo de particularidad la flecha se elimina. Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente. Dependencia o Instanciación (uso): Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

Proyecto # 1

38

Análisis y Diseño con Orientación a Objeto El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicación): Diagrama de Interacción El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Los componentes de un diagrama de interacción son: 6.Un Objeto o Actor. Mensaje de un objeto a otro objeto. Mensaje de un objeto a si mismo Objeto/Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto. Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular. Mensaje al Mismo Objeto:

Proyecto # 1

39

Análisis y Diseño con Orientación a Objeto No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio. Casos de Uso (Use Case) El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:
  

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.

Actor:

Un Actor es un rol que un usuario juega con respecto al sistema. Un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Caso de Uso: Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Proyecto # 1

40

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

Relaciones: Tipos de Relaciones Es el tipo de relación más básica que Asociación indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Símbolo Descripción

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.

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que Generalización puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). uses: Se recomienda utilizar cuando se tiene un conjunto

Proyecto # 1

41

Análisis y Diseño con Orientación a Objeto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. Tutorial UML UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notación y semántica común. Modelos Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Clases: Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Ejemplo de una clase Lámpara Lámpara mensaje Prender() Apagar() Proyecto # 1 42

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

Objetos Un objeto se representa de la misma forma que una clase. En el compartimiento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados. Asociaciones Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación. Nombre de la Asociación y Dirección El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea. Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación. Ejemplo: JEFE Manda sobre EMPLEADO

Herencia La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase “padre”. MAMIFEROS

Perro

Gato

Diagrama de Casos de Uso

Proyecto # 1

43

Análisis y Diseño con Orientación a Objeto Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.

Estacion de gasolina
Apagar el auto

Hacer pedido

Cliente

Entregar dinero

Depositar gasolina

Proyecto # 1

Recibir pago

44

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

Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Casos de Uso Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Relaciones entre Casos de Uso Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Diagramas de Interacción En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la Proyecto # 1 45

Análisis y Diseño con Orientación a Objeto misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.

Diagrama de Secuencia Un diagrama de Secuencia muestra una interacción ordenada según la En particular, muestra los objetos

secuencia temporal de eventos. según su secuencia en el tiempo.

participantes en la interacción y los mensajes que Diagrama de Colaboración

intercambian ordenados

Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos.

Proyecto # 1

46

Análisis y Diseño con Orientación a Objeto Fátima González UML UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa (principalmente Booch, OMT y OOSE). Los modelos de UML que se tratan en esta parte son los siguientes:  Diagrama de Estructura Estática.
   

Diagrama de Casos de Uso. Diagrama de Secuencia. Diagrama de Colaboración. Diagrama de Estados.

MODELO DE CLASES Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento. Un diagrama de clases esta compuesto por los siguientes

elementos:
 

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

CLASE Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemática, con los atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase.

Proyecto # 1

47

Análisis y Diseño con Orientación a Objeto ATRIBUTOS Y MÉTODOS: Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

public (+,

): Indica que el atributo será visible tanto dentro como

fuera de la clase, es decir, es accsesible desde todos lados.

private (-,

): Indica que el atributo sólo será accesible desde dentro

de la clase (sólo sus métodos lo pueden accesar).

protected (#,

): Indica que el atributo no será accesible desde fuera

de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia). Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

public (+,

): Indica que el método será visible tanto dentro como

fuera de la clase, es decir, es accesesible desde todos lados.

private (-,

): Indica que el método sólo será accesible desde dentro

de la clase (sólo otros métodos de la clase lo pueden acceder).

protected (#,

): Indica que el método no será accesible desde fuera

de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). OBJETOS: Un objeto se representa de la misma forma que una clase. siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase según la Puede

representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase.

Proyecto # 1

48

Análisis y Diseño con Orientación a Objeto RELACIONES ENTRE CLASES: Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
  

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

Herencia (Especialización/Generalización): Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected). Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación. Asociación:

Proyecto # 1

49

Análisis y Diseño con Orientación a Objeto La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente. Dependencia o Instanciación (uso): Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

CASOS PARTICULARES:

Clase Abstracta: Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos. Clase parametrizada: Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos.

Proyecto # 1

50

Análisis y Diseño con Orientación a Objeto DIAGRAMA DE INTERACCIÓN El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente. Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes). Los componentes de un diagrama de interacción son:
  

Un Objeto o Actor. Mensaje de un objeto a otro objeto. Mensaje de un objeto a si mismo.
El rectángulo representa una instancia de un objeto en particular, y la línea punteada

Elementos Objeto/Actor:

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos

Proyecto # 1

51

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

CASOS DE USO (USE CASE) El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:
  

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.

ACTOR:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

CASO DE USO:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. RELACIONES: Asociación

Proyecto # 1

52

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

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

Proyecto # 1

53

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

b) Basado en Eventos 1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso. Identificación de los Límites del Sistema En la descripción de un caso de uso se hace referencia en todo momento al “sistema”. Para que los casos de uso tengan un significado completo es necesario que el sistema esté definido con precisión. Al definir los límites del sistema se establece una diferenciación entre lo que es interno y lo que es externo al sistema. El entorno exterior se representa mediante los actores. Ejemplos de sistemas son:
  

El hardware y software de un sistema informático. Un departamento de una organización. Una organización entera.

Proyecto # 1

54

Análisis y Diseño con Orientación a Objeto ANNETH MANZANÉ UML El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software orientado a objetos.. Un modelo representa a un sistema software desde una perspectiva específica. Los modelos de UML que se presentarán en este resumen son los siguientes:
    

Diagrama de Clase Diagrama de Interacción Diagrama de Casos de Uso. Diagrama de Estados. Diagrama de Componentes

DIAGRAMA DE MODELO DE CLASES Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento. Un diagrama de clases esta compuesto por los siguientes elementos:
 

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

ELEMENTOS DE UNA CLASE Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). nombre de la clase, sus atributos y operaciones ó En UML, una clase es representada por un rectángulo que posee tres divisiones: el métodos.

Proyecto # 1

55

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

Atributos: Los atributos o características de una Clase pueden ser de tres tipos que son: public (+, ): Indica que el atributo será todas las clases accesible desde

private (-, ): Indica que el atributo sólo será accesible dentro de la clase o sea que sólo sus métodos pueden acceder. protected (#, ): Indica que el atributo no será accesible fuera de la clase, pero si podrá ser accesado por métodos de la clase. Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: public (+, ): Indica que el método será accesible desde

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

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

fuera de la clase, pero si podrá ser accesado por métodos de

Relaciones entre Clases:

Proyecto # 1

56

Análisis y Diseño con Orientación a Objeto Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

Objeto Un objeto se representa de la misma forma que una clase. En el compartimiento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase .Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase. Elementos Comunes a Todos los Diagramas

Notas: Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc; por ejemplo:

Herencia (Especialización/Generalización):

Proyecto # 1

57

Análisis y Diseño con Orientación a Objeto Indica que una subclase hereda los métodos y atributos especificados por una Super Clase. La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase “padre”.

Agregación: Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: 1. Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición. 2. Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación.

Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si y el tiempo de vida de un objeto no depende del otro. Multiplicidad La multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase.

Proyecto # 1

58

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

Navegabilidad: Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino. Se trata de un concepto de diseño, que indica que un objeto de la clase origen conoce al (los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus operaciones.

Dependencia o Instanciación (uso): El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra. Casos Particulares:

Clase Abstracta: Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Clase parametrizada: Se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada.

DIAGRAMA DE INTERACCIÓN En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.

Diagrama de Secuencia:

Proyecto # 1

59

Análisis y Diseño con Orientación a Objeto Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo.

Diagrama de Colaboración: Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A diferencia de los Diagramas de Secuencia, muestran las relaciones entre los roles de los objetos.

Componentes de un diagrama de interacción son: Objeto/Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto. Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llama a métodos de objetos externos, también visualiza llamadas a métodos desde el mismo objeto en estudio.

Proyecto # 1

60

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

DIAGRAMA CASOS DE USO Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. Un diagrama de casos de uso consta de los siguientes elementos: Actor:

Un Actor es un rol que un usuario juega con respecto al sistema. Un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación de otro caso de uso.

Relaciones: 1. Asociación 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). 2. 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).

Proyecto # 1

61

Análisis y Diseño con Orientación a Objeto 3. 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>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso.

Aquí se presenta un diseño completo del diagrama Caso de Uso:

DIAGRAMAS DE ESTADO Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien Proyecto # 1 62

Análisis y Diseño con Orientación a Objeto todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. Modelado Físico De Un Sistema OO

Componentes: Los componentes pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar aspectos físicos de un sistema. Una característica básica de un componente es que: “debe definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles.” En UML todos los elementos físicos se modelan como componentes.

Interfaces: Tanto los servicios propios de una clase como los de un componente, se especifican a través de una Interfaz. Por ejemplo, todas las facilidades más conocidas de los sistemas operativos, basados en componentes, utilizan las interfaces como lazo de unión entre unos componentes y otros.

Tipos de componentes: Existen básicamente tres tipos de componentes:

Componentes necesarios y ejecutable.

de

despliegue:

componentes

suficientes para formar un sistema

Componentes producto del trabajo: Consisten en cosas como archivos de código fuente y de datos a partir de los cuales se crean los componentes de despliegue. Componentes de ejecución: son componentes que se crean como consecuencia de un sistema en ejecución.

Organización de componentes: Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases. Además se pueden

Proyecto # 1

63

Análisis y Diseño con Orientación a Objeto especificar realización. Despliegue

entre

ellos

relaciones (incluyendo

de

dependencia, agregación), y

generalización,

asociación

Nodos: Es un elemento físico, que existe en tiempo de ejecución y representa un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento.

Nodos y componentes: Los nodos y los componentes tienen características parecidas. Vamos a ver con más detalle cuales son los parecidos y las diferencias entre los componentes y los nodos.

Parecidos: Ambos tienen nombre Pueden participar en relaciones de dependencia, generalización y asociación. Ambos pueden anidarse Ambos pueden tener instancias Ambos pueden participar en interacciones

Diferencias

Los Nodos Los Componentes Son los elementos donde se ejecutan los componentes. Son los elementos que participan en la ejecución de un sistema. Representan el despliegue físico de los componentes. Representan el empaquetamiento físico de los elementos lógicos. DIAGRAMAS DE COMPONENTES Proyecto # 1

64

Análisis y Diseño con Orientación a Objeto Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. PROCESO DE DESARROLLO Cuando se va a construir un sistema software es necesario conocer un lenguaje de programación, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solución sea cuidadosamente diseñada. Si se sigue un proceso de desarrollo que se ocupa de plantear cómo se realiza el análisis y el diseño, y cómo se relacionan los productos de ambos, entonces la construcción de sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo formado por varias personas.

Proyecto # 1

65

Análisis y Diseño con Orientación a Objeto CONSENSO Diagrama UML El Lenguaje de Modelamiento Unificado (Uml). Es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. El documento contempla el estudio de tres diagramas:
  

Modelamiento de Clases Casos de Uso Diagrama de Interacción

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

Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Modelo de clases : Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema. Un diagrama de clases esta compuesto por los siguientes elementos: Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Objeto: un objeto es una instancia de una clase. Atributos: Los atributos o características de una Clase pueden ser de tres tipos que son:

Proyecto # 1

66

Análisis y Diseño con Orientación a Objeto public (+, ): Indica que el atributo será todas las clases accesible desde

private (-, ): Indica que el atributo sólo será accesible dentro de la clase o sea que sólo sus métodos pueden acceder. protected (#, ): Indica que el atributo no será accesible fuera de la clase, pero si podrá ser accesado por métodos de la clase. Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: public (+, las clases. private (-, acceder. protected (#, ): Indica que el método no será accesible fuera ): Indica que el método sólo será accesible dentro ): Indica que el método será accesible desde todas

de la clase o sea que sólo otros métodos de la clase lo pueden

de la clase, pero si podrá ser accesado por métodos de la clase. Encapsulamiento: El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. Abstracción: La abstracción consiste en captar las características esenciales de un objeto, así como su comportamiento.

RELACIONES ENTRE CLASES: Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). Proyecto # 1 67

Análisis y Diseño con Orientación a Objeto Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
  

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

Herencia (Especialización/Generalización): Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected). Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación. Asociación:

Proyecto # 1

68

Análisis y Diseño con Orientación a Objeto La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Dependencia o Instanciación (uso): Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es denota por una flecha punteada. DIAGRAMA DE INTERACCIÓN El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente. Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes). dependiente de otro objeto/clase). Se

Los componentes de un diagrama de interacción son:
  

Un Objeto o Actor. Mensaje de un objeto a otro objeto. Mensaje de un objeto a si mismo.

DIAGRAMA CASOS DE USO Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. Un diagrama de casos de uso consta de los siguientes elementos: Proyecto # 1 69

Análisis y Diseño con Orientación a Objeto Actor:

Un Actor es un rol que un

usuario juega con respecto al

sistema. Un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación de otro caso de uso.

Relaciones: 1. Asociación 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). 2. 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). 3. 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>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto 70

Proyecto # 1

Análisis y Diseño con Orientación a Objeto de características que son similares en más de un caso de uso. Identificación de Casos de Uso La identificación de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisión de los documentos de requisitos existentes, y en el uso de la técnica de brainstorming entre los miembros del equipo de desarrollo. Como guía para la identificación inicial de casos de uso hay dos métodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organización. 2. Para cada actor, identificar los procesos que inicia o en los que participa. b) Basado en Eventos 1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso.

Proyecto # 1

71

Sign up to vote on this title
UsefulNot useful