Apunte MOO 2007

Anlisis de Sistemas
Metodologa
Orientada a Objetos
- UML
- 2005 -
Anlisis de Sistemas
Metodologa Orientada a Objetos
ndice
Introduccin ....................................................................................................................... 3
La importancia de modelar ................................................................................................ 4
Tcnica de Modelado de Objetos (OMT)........................................................................... 5
Conceptos bsicos de Orientacin a Objetos................................................................ 5
Diferencias entre la metodologa orientada a objetos y los mtodos estructurados...... 7
Breve historia de UML ....................................................................................................... 8
Caractersticas de UML ..................................................................................................... 8
Diagramas en UML............................................................................................................ 9
Diagrama de Casos de Uso......................................................................................... 10
Diagrama de Clases .................................................................................................... 13
Diagrama de Clases .................................................................................................... 15
Diagrama de Secuencia .............................................................................................. 21
Diagrama de Colaboracin .......................................................................................... 24
Diagrama de Estados .................................................................................................. 26
Diagrama de Actividades ............................................................................................. 28
Diagrama de Componentes ......................................................................................... 30
Diagrama de Deployment ............................................................................................ 31
Relaciones en UML ......................................................................................................... 32
Caso Prctico .................................................................................................................. 33
Caso N1: Metodologa Orientada a Objetos............................................................... 35
Caso N2: Metodologa Estructurada .......................................................................... 41
Anexo 1: Plantilla Caso de Uso ....................................................................................... 43
Glosario ........................................................................................................................... 44
Bibliografa....................................................................................................................... 47
UTN-Universidad Tecnolgica Nacional
Pgina 2 de 2
Anlisis de Sistemas
Introduccin
En el desarrollo de sistemas, se encuentran las fases de anlisis y diseo.
La Fase de Anlisis consiste en:
Establecer una visin clara del problema a resolver.
Definir un panorama general de las tareas que el sistema deber realizar. Es decir,
el QU del sistema.
Definir un vocabulario comn (glosario).
Plantear alternativas de solucin.
La Fase de Diseo consiste en:
Definir el CMO del sistema.
Resolver el problema.
Definir una estrategia de implementacin.
Adems, uno de los objetivo de las mismas es la creacin de un modelo de sistema. Este
modelo, como todos, es una representacin de la realidad, pero no ser el nico, sino que
existen otros modelos posibles para poder representarla. Es por esto que se pueden utilizar
diferentes paradigmas o metodologas para poder modelar un mismo sistema.
Algunas de los paradigmas de modelado son:
Orientacin funcional (estructurada): este se focaliza en las funciones y subfunciones
que componen el sistema y en la forma en que se relacionan entre si. Se da importancia a
los procesos.
Orientacin a objetos: Se centra en los objetos que representan entidades del sistema,
las cuales contienen atributos y funciones asociadas.
Pgina 3 de 3
Anlisis de Sistemas
La importancia de modelar
Los modelos proporcionan una visin del sistema. Los modelos pueden involucrar una
visin detallada, como as tambin ms general. De esta manera, se encontrarn
elementos que son ms o menos relevantes segn el nivel de abstraccin dado.
Los modelos pueden ser expresados a diferentes niveles de precisin, es decir, que
pueden haber modelos con distintos grados de detalles.
Hay varias razones importantes por las que se modelan los sistemas, estas son:
Para tener una mayor comprensin del sistema implicado, ya que los modelos
ayudan a visualizar cmo es o queremos que sea un sistema. Adems, permite
especificar el comportamiento del mismo y documentar las decisiones que se han
tomado.
Porque no se pueden comprender los sistemas en su totalidad, cuando stos son

muy grandes o complejos. De esta manera, se reduce el problema que se est
estudiando, focalizndose slo en un aspecto a la vez.
Cabe aclarar, que el modelado no es nicamente importante para los sistemas grandes o
complejos, sino que adems los sistemas pequeos se ven beneficiados cuando se los
modela.
Pgina 4 de 4
Anlisis de Sistemas
Tcnica de Modelado de Objetos (OMT)

La Tcnica de Modelado de Objetos (OMT), es un procedimiento que se basa en aplicar el
enfoque orientado a objetos a todo el proceso de desarrollo de un sistema software, desde
el anlisis hasta la implementacin. Los mtodos de anlisis y diseo que propone son
independientes del lenguaje de programacin que se emplee.
OMT es una metodologa orientada a objetos de desarrollo de software basada en una
notacin grfica para representar conceptos orientados a objetos.
La visin del modelado de sistemas orientado a objetos est basada en tratar de ver el
problema y ver su solucin como un conjunto de objetos o clases que interactan entre si.
Conceptos bsicos de Orientacin a Objetos

Objeto: es una unidad atmica que posee un estado y un comportamiento. El estado est
determinado por el valor que toman los atributos del objeto en un instante dado. Un objeto
representa una entidad fsica, como por ejemplo un auto, o bien una entidad abstracta,
como puede ser un proceso de contabilidad.
Son instancias de una clase (molde que sirve para crear instancias).
Abstraccin:
Se ignoran detalles para centrarse en caractersticas esenciales. Permite simplificar la
informacin acerca del objeto.
Encapsulamiento:
Los datos estn escondidos dentro del objeto. Permite determinar qu informacin es
publicada y qu informacin es ocultada al resto de los objetos. Para ello los objetos suelen
presentar sus mtodos como interfaces pblicas y sus atributos como datos privados,
quedando de esta manera inaccesibles desde otros objetos.
El encapsulamiento permite reducir la complejidad, ya que las Clases se tratarn como
cajas negras donde slo se conoce el comportamiento pero no los detalles internos.
Ejemplo : Un auto oculta su funcionamiento en su interior. Un usuario puede operarlo sin
necesidad de entender sus funciones internas.
Asociacin:
Forma de interaccin entre objetos. Dos objetos estn asociados cuando uno usa
servicios u operaciones brindados por el otro.
Consiste en la extraccin de las propiedades fundamentales de un concepto. Permite no
preocuparse por los detalles no esenciales, es decir, no es necesario conocer los detalles
exactos de la implementacin.
Agregacin:
Es un tipo particular de asociacin. Describe una relacin tiene un...
Se refiere al concepto de definir un objeto en trminos de sus componentes.
Composicin:
Es un tipo particular de asociacin. Describe una relacin contiene...
Indica que un objeto no puede existir sin contener a otro.
Cohesin:
Es el grado de relacin entre clases en relacin a un propsito dentro del sistema.
Acoplamiento:
Indica el nivel de dependencia entre objetos.
Pgina 5 de 5
Anlisis de Sistemas
Es deseable tener bajo acoplamiento y alta cohesin.

Herencia:
Permite definir una nueva clase en trminos de otra clase ya existente. Describe una
relacin es un ...
Polimorfismo:
Mecanismo basado en herencia. Permite redefinir una misma operacin para dos o ms
clases relacionadas mediante herencia.
El comportamiento de una operacin polimrfica depende del objeto en concreto sobre la
cual es aplicada.
Pgina 6 de 6
Anlisis de Sistemas
Diferencias entre la metodologa orientada a objetos y los mtodos

estructurados
El Anlisis Orientado a Objetos, ofrece un enfoque distinto para el anlisis de sistemas. En
lugar de considerar el sistema desde una perspectiva clsica de entrada/proceso/salida,
como los mtodos estructurados, se basa en modelar el sistema mediante los objetos que
forman parte de l y sus relaciones estticas y dinmicas. Este enfoque pretende conseguir
modelos que se ajusten mejor al problema real.
El Anlisis Orientado a Objetos consigue una abstraccin mayor que el anlisis
estructurado, que modela los sistemas desde un punto de vista ms prximo a su
implementacin en una computadora (entrada-proceso-salida).
El uso de Anlisis Orientado a Objetos puede facilitar mucho la creacin de prototipos, y
las tcnicas de desarrollo evolutivo de sistemas. Los objetos son reutilizables, y se puede
crear un conjunto de objetos que se pueden usar en sucesivas aplicaciones. De esta
forma, se puede obtener rpidamente un prototipo del sistema.
El anlisis estructurado se basa fundamentalmente en la descomposicin funcional del
sistema que se desea construir. Esta descomposicin funcional requiere traducir el dominio
del problema en una serie de funciones y subfunciones. El analista debe comprender
primero el dominio del problema y a continuacin documentar las funciones y subfunciones
que proporciona el sistema.
El paradigma orientado a objetos pone especial nfasis en la reutilizacin, y proporciona
mecanismos que permiten reutilizar aquello que es comn, sin impedir por ello describir las
diferencias.
Los cambios en los requisitos afectan notablemente a la funcionalidad de un sistema, por lo
que afectan mucho al software desarrollado con mtodos estructurados. Sin embargo,
segn afirman sus creadores, los cambios afectan en mucha menor medida a los objetos
que componen o maneja el sistema, que son mucho ms estables. Las modificaciones
necesarias para adaptar una aplicacin basada en objetos a un cambio de requisitos
suelen estar mucho ms localizadas.
Pgina 7 de 7
Anlisis de Sistemas
Breve historia de UML

Algunos de los lenguajes de modelado orientado a objetos surgieron entre los aos 70-80.
Luego, entre los aos 1989-1994, el nmero de estos lenguajes comenz a crecer debido
al auge que tuvo en esos tiempos la Programacin Orientada a Objetos.
El desarrollo de UML (Unified Modelling Languaje) comenz en 1994, cuando Grady
Booch y Jim Rumbaugh, unificaron sus obras (Booch-93 y OMT, respectivamente) en un
nico lenguaje de modelado para el anlisis y el diseo orientado a objetos. Esto dio lugar,
en 1995, a la versin 0.8 de UML y es en este momento cuando un nuevo integrante,
Jacobson, se uni, aportando a UML el concepto de Caso de Uso.
El desarrollo de UML atrajo a muchas empresas del gnero informtico, las cuales
pudieron apreciar en este lenguaje de modelado, una alternativa para el anlisis y diseo
de las aplicaciones orientadas a objetos.
En 1997, se present a la OMG (grupo encargado de ratificar y aceptar los estndares
relacionados con la orientacin a objetos) la versin 1.0, que luego sera aprobada.
Todas las actualizaciones y modificaciones de UML las realiza la OMG.
Caractersticas de UML
UML es un lenguaje en gran parte grfico, que permite representar modelos de sistemas.
Permite visualizar, especificar, construir y documentar los elementos que componen a un
sistema.
Por lo tanto, UML, consta de una notacin grfica para representar los elementos
participantes en un desarrollo orientado a objetos. Adems, permite describir las fases de
Anlisis y Diseo.
UML posee diversos diagramas que permiten describir distintas vistas de un sistema.
UML es independiente del proceso, es decir, que no est ligado a ningn modelo de ciclo
de vida (cascada, espiral, etc.).
Pgina 8 de 8
Anlisis de Sistemas
Diagramas en UML
Los diagramas son la representacin grfica de un conjunto de elementos y cada uno de
ellos muestra una vista del sistema que se modela.
UML define varios tipos de diagramas que se utilizan para describir diferentes aspectos de
un sistema. En algunos diagramas se centra la atencin en los aspectos estticos y en
otros en los dinmicos.
No siempre es necesario realizar todos los tipos de diagramas, sino slo aquellos
que son representativos para el problema que se est tratando. Es decir, que en
funcin del tipo de sistema que se est modelando, algunos de los diagramas pueden ser
innecesarios.
UML cuenta con nueve tipos de diagramas, que son los siguientes:
Diagramas Estticos (Estructurales): se utilizan para visualizar, especificar, construir y
documentar los aspectos estticos (estables) del sistema. stos son:
Diagrama de Casos de Uso.
Diagrama de Clases.
Diagrama de Objetos.
Diagrama de Componentes.
Diagrama de Distribucin/Despliegue (deployment).
Diagramas de Comportamiento: se utilizan para visualizar, especificar, construir y
documentar los aspectos dinmicos (mutables) del sistema. stos son:
Diagrama de Secuencia.
Diagrama de Colaboracin.
Diagrama de Estados.
Diagrama de Actividades.
A continuacin se har una breve explicacin de cada uno de ellos:
Pgina 9 de 9
Anlisis de Sistemas
Diagrama de Casos de Uso

Antes de describir que es un diagrama de casos de uso, se definirn algunos conceptos
necesarios para su comprensin:
Casos de Uso
Los casos de uso son una descripcin de un conjunto de secuencias de acciones
(interacciones de los actores con el sistema), que ejecuta un sistema para obtener un
resultado, el cual es de valor para un actor.
Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con
otros actores, intercambian datos con el sistema, participando de ese caso de uso.
Los casos de uso especifican un comportamiento deseado (describen qu hace el sistema
o subsistema), pero no imponen cmo se llevar a cabo ese comportamiento.
En UML, todos esos comportamientos se modelan a travs de casos de usos.
Permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno.
El nombre que posee el caso de uso, siempre est expresado desde el punto de vista del
actor y no desde el punto de vista del sistema.
Cabe aclarar que los casos de uso no tienen que ver con entender a un sistema como un
conjunto de objetos, es decir, que no slo se utiliza casos de uso con el paradigma
orientado a objetos, sino que tambin se los usa en el estructurado.
Los casos de uso presentan las siguientes caractersticas:
Estn expresados desde el punto de vista del actor.

Se documentan con texto informal.
Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta
con l, pero poniendo nfasis en la interaccin.
Son iniciados por un nico actor.
Utilidad de los Casos de Uso

Los casos de uso se utilizan para lo siguiente:
Para modelar el contexto de un sistema.

Para identificar y organizar actores.
Para modelar los requisitos de un sistema.
Para especificar qu debera hacer el sistema desde el punto de vista externo sin
importar como se haga.
Para documentar los requisitos de un sistema.
Para documentar las funciones del sistema y los roles de cada actor interviniente.
Pgina 10 de 10
Anlisis de Sistemas
Documentacin de Casos de Uso

Una vez que se identifican los casos de uso, se comienzan a documentar sus pasos. Este
documento se crea para cada caso de uso, detallando lo que el sistema debe proporcionar
al actor cuando el caso de uso es ejecutado.
La documentacin de casos de uso podra consistir en lo siguiente:
Describir cmo comienza el caso de uso y cmo termina (precondiciones y
poscondiciones).
Realizar un flujo normal de eventos.
Realizar un flujo alterno de eventos.
Detallar las excepciones al flujo de eventos.
Actores del sistema.
Ver Anexo 1: Plantilla Caso de Uso
Relaciones de Extensin y de Inclusin

En los sistemas se pueden encontrar casos de uso que son especializaciones de otros
casos de usos, como as tambin, casos de usos incluidos como parte de otro y casos de
usos que extienden el comportamiento de otros casos de uso bsicos.
Una relacin de extensin (extend) entre casos de uso, significa que uno de ellos
incorpora implcitamente el comportamiento del otro caso de uso. Una relacin de
extensin se utiliza para modelar la parte de un caso de uso que el usuario puede ver
como comportamiento opcional del sistema. De esta manera, se separa el comportamiento
opcional del obligatorio o del de aquel que se ejecuta bajo ciertas condiciones, ya que
muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que
ocurren slo en algunas oportunidades.
La relacin de extensin se representa por una lnea de trazos desde el caso que extiende
a al caso que es extendido.
Una relacin de inclusin (include), entre casos de uso, significa que un caso de uso
incorpora explcitamente el comportamiento de otro caso de uso. Es decir, el caso de uso
base toma el comportamiento del caso de uso proveedor.
La relacin de inclusin se usa para evitar describir el mismo flujo de eventos repetidas
veces, poniendo el comportamiento comn en un caso de uso aparte (que ser incluido
por un caso de uso base).
La principal diferencia que existe entre las relaciones Include y la Extend, es que la relacin
extend cuenta con una condicin a ser evaluada. En cambio, la relacin include se define
como la inclusin de un Caso de Uso en otro, pero no precisa de una condicin.
De esta manera, se puede decir que la relacin include puede considerarse como un caso
particular de la relacin extend
Pgina 11 de 11
Anlisis de Sistemas
Actores
Otro concepto muy relacionado con los casos de uso son los actores.
Un Actor representa un conjunto de roles que los usuarios de los casos de uso juegan al
interactuar con ellos. Este rol o roles es llevado a cabo por una persona, un dispositivo de
hardware u otro sistema.
La misma persona fsica puede interpretar varios papeles como actores distintos. El
nombre del actor describe el papel desempeado.
Los actores pueden conectarse a los casos de uso slo a travs de asociaciones.
Una asociacin indica una relacin entre un actor y un caso de uso y la posibilidad que
tienen stos de comunicarse, es decir, enviar y recibir mensajes.
Los actores son externos al sistema. Es por ello, que al identificar a los actores se est
delimitando el sistema.
Cabe aclarar la diferencia existente entre usuario y actor. Un actor es una clase de rol,
mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De
esta manera, un usuario puede acceder al sistema como distintos actores.
Identificar a los actores es el primer paso para usar la tcnica de casos de uso.

Este diagrama muestra un conjunto de casos de usos, actores y las relaciones entre ellos.
Cada una de estas relaciones o interacciones, comienzan con un evento inicial que el actor
enva al sistema y contina con una serie de eventos entre el actor, el sistema y
posiblemente otros actores involucrados. Muestra el comportamiento del sistema o de una
parte del mismo y su interaccin con los actores exteriores al sistema. Representa el
aspecto esttico de los casos de uso.
Los diagramas de casos de uso contienen:
Casos de uso.
Actores.
Relaciones de asociacin, inclusin y extensin.
Sistema de Validacin de
Tarjetas de Crdito
Realizar
transaccin con
tarjeta
Cliente
Comercio
Procesar Factura
del Cliente
Cliente
Particular
Cliente
Corporativo
Gestionar Cuenta
del Cliente
Entidad
Financiera
Nota: Para obtener ms informacin leer Apunte: Casos de Uso de la ctedra.
Pgina 12 de 12
Anlisis de Sistemas
Diagrama de Clases
Antes de describir que es un diagrama de clases, se definirn algunos conceptos
Clase:
Una clase describe un conjunto de objetos que tienen en comn los mismos atributos,
operaciones, relaciones y semntica.
Una clase normalmente incluye su nombre, atributos y operaciones (mtodos).
Los atributos identifican datos de los objetos de la clase y los mtodos especifican sus
operaciones o comportamiento.
Instancias, son los objetos que componen cada clase. Una vez que una instancia es
creada su comportamiento es igual al comportamiento de las otras instancias. A stas, se
le aplican un conjunto de operaciones.
Muchos de los atributos y mtodos se conocen recin en la fase de diseo. No obstante,
hay otros que se evidencian en la fase de anlisis y deben incluirse en el diagrama en
cuanto se detectan.
La estructura bsica de una clase pude verse en el siguiente grfico:
NombreClase
atributos
mtodos
Ejemplo:
ESTUDIANTE
-NroLegajo: long
-DNI: long
-Apellido: string
-Nombre: string
+Alta()
+VerExpediente()
Clase
Atributos
Operaciones
Tipos de Clases
Clase Abstracta: Son aquellas clases que no crean o producen instancias de s mismas.
Es decir, este tipo de clase puede tener herederas (clases descendientes), pero no puede
ser instanciada. Genera un comportamiento comn que ser definido una sola vez en esta
clase abstracta y heredado por sus subclases.
Pueden contener mtodos abstractos (o sea, mtodos cuyo comportamiento no est
definido en esa clase).
Una clase que hereda de una clase abstracta hereda todos sus mtodos (incluidos los
abstractos).
Cualquier clase que herede un mtodo abstracto se considera abstracta a no ser que
defina un comportamiento para dicho mtodo.
Pgina 13 de 13
Anlisis de Sistemas
El comportamiento de los mtodos no se define en la etapa de anlisis.

Las clases abstractas se representan poniendo el nombre de la clase en cursiva. Los
mtodos abstractos tambin van en cursiva.
Clase Concreta: Es aquella de la cual pueden generarse instancias particulares (objetos).
Superclase: Es la clase de donde se heredan los comportamientos y/o estructura.
Subclase: Es una clase que hereda el comportamiento de otra clase.
Clase de asociacin: Son clases que no aparecen fsicamente entre las clases del
sistema. Estn vinculadas a una asociacin entre clases.
Ejemplo: se desea representar las notas que tiene un estudiante en cada una de las
materias que est cursando:
Estudiante
Materia
Apellido
Nombre
Cdigo
Nombre
Alta()
Baja()
Alta()
Baja()
Calificacin
Nota
La clase de asociacin puede relacionarse con otras clases de igual modo que una clase
comn del diagrama.
Otros conceptos
Interfaz
Una interfaz es un conjunto de operaciones que especifican un servicio de una clase,
pudiendo representar el comportamiento completo de la clase o slo una parte. Es un tipo
especial de clase que no posee atributos y en la cual todos sus mtodos son abstractos.
Las clases no extienden una interfaz, sino que la implementa. Las clases pueden
implementar muchas interfaces.
Grficamente se representa de la siguiente manera:
Nombre
Pgina 14 de 14
Anlisis de Sistemas
Colaboracin
Son el conjunto de elementos del sistema que brindan un comportamiento cooperativo
mayor a la suma de los comportamientos de los elementos. Es la especificacin de cmo
se realiza un elemento.
Herencia
Mecanismo por el cual elementos ms especficos (subclase) incorporan la estructura y
comportamiento de los elementos ms generales (superclase).
Herencia mltiple: indica que una clase extiende o hereda de ms de una clase base.
Hay que tener en cuenta, que no todos los lenguajes de programacin permiten herencia
mltiple. Por ejemplo, C++ la permite, pero no ocurre lo mismo con Java. La herencia
mltiple puede simularse mediante interfaces.
Responsabilidades
Las responsabilidades de un objeto son todos los servicios que l provee. Las
responsabilidades incluyen:
El conocimiento que el objeto tiene.
Las acciones que un objeto puede realizar.
Diagrama de Clases
Es un diagrama que describe las clases que se deben crear en el sistema junto con las
relaciones existentes entre ellas.
Representa el modelo esttico del sistema. En l se nombrarn a todas las clases con sus
atributos y mtodos y las relaciones existentes. Se modelarn las colaboraciones y el
esquema lgico de la base de datos.
El diagrama de clases surge del conjunto de requerimientos y de los casos de uso del
sistema. Se comienza a crear a partir de las clases y objetos candidatos identificados
durante la etapa de requerimientos.
Tipos de Diagramas de Clases:
Diagrama de Clases Conceptual: son los que se construyen en la etapa de anlisis. En
stos no se incluyen los tipos de los atributos, ni los mtodos.
Diagrama de Implementacin: son los que se construyen en la etapa de diseo. En estos
se agrega informacin ms especfica, tipos de los atributos, se incluyen todos los
mtodos.
Relaciones y Multiplicidades
Dos clases del diagrama pueden relacionarse entre s, mediante una asociacin. Las
relaciones entre clases surgen del documento de requerimientos y del dominio del
problema.
Las asociacin se representa mediante una lnea que une las clases involucradas. stas
asociaciones poseen un nombre y un sentido.
La multiplicidad se incluye en ambos extremos de una lnea de asociacin entre dos
clases.
Pgina 15 de 15
Anlisis de Sistemas
Los tipos de multiplicidades que se presentan son los siguientes:

*
1
1..*
0..1
Muchos
Uno
Una o muchas (obligatorio)
Cero o una (opcional)
De esta manera, se deber marcar cada extremo de la lnea de asociacin con la cantidad
de instancias de la clase correspondiente a ese extremo que pueden relacionarse con
una instancia de la clase que se encuentra en el otro extremo.
Ejemplo:
Estudiante
5..*
cursa
0..*
Materia
Es decir, un Estudiante cursa cero o muchas Materias (se asume que puede no cursar
ninguna materia) y una Materia puede ser cursada por cinco o muchos Estudiantes (se
asume que una materia al menos va a ser cursada por cinco estudiantes).
Pgina 16 de 16
Anlisis de Sistemas
Ejemplo 1:
En este caso, una Persona tiene Vehculo. A su vez, un Vehculo puede ser tanto una
Moto, como un Auto.
Moto y Auto heredan de Vehculo el atributo matrcula y los mtodos verMatrcula y
cantRuedas. El mtodo cantRuedas es redefinido por las clases Moto y Auto.
Vehculo
Persona
nombre
matrcula
verMatrcula()
cantRuedas()
Moto
Auto
cantRuedas()
cantRuedas()
Pgina 17 de 17
Anlisis de Sistemas
Ejemplo 2:
En este caso, cada clase posee todos los atributos y mtodos que implementar. Se
pueden apreciar, adems, las relaciones de agregacin, como as tambin las
multiplicidades de cada clase.
Pgina 18 de 18
Anlisis de Sistemas
Diagrama de Objetos
Antes de describir que es un diagrama de Objetos, se definirn algunos conceptos
Relacin: vinculacin entre objetos.
Instancia: son los objetos que componen cada clase. Una vez que una instancia es creada
su comportamiento es igual al comportamiento de las otras instancias. A stas, se le
aplican un conjunto de operaciones.
Este diagrama muestra un conjunto de objetos junto a sus relaciones. Representa el
aspecto esttico del sistema y se lo puede considerar como una foto del diagrama de
clases en un momento dado, sustituyendo a la clase por una instancia de ella.
El diagrama de Objetos parte del diagrama de Clases.
La clase a la cual pertenece el objeto debe incluirse como parte del nombre.
En el rectngulo inferior se
colocan valores concretos
que toman los atributos
para ese objeto. Si estos
atributos no se conocen,
se omiten.
nombreObjeto : Clase
valores de atributos
Relaciones entre objetos

Los objetos se relacionan entre si, a travs de Asociaciones.
Objeto1 : Clase1
Apellido: Perez
Asociacin
Objeto2 : Clase2
Materia: Anlisis de
Sistemas
Pgina 19 de 19
Anlisis de Sistemas
Multiplicidad
La multiplicidad en los diagramas de objetos es siempre 1 en ambos extremos, ya que se
tratan de instancias de las clases. Se puede incluir un nombre de relacin.
De un objeto perteneciente a una clase (por ejemplo de la Clase1) pueden salir varias
relaciones hacia objetos de otra clase (por ejemplo Clase2). Esto sucede en caso de que la
multiplicidad correspondiente al extremo de la Clase2 en el diagrama de clases sea mayor
a 1.
Objeto1 : Clase1
Apellido: Perez
: Clase2
Materia: Anlisis de
Sistemas
: Clase2
Materia: Fsica
Los diagramas de Objetos contienen (en general), los siguientes elementos:

Objetos.
Relaciones (Enlaces).
Ejemplo:
Siguiendo con el mismo ejemplo que para el Diagrama de Clases, a continuacin se puede
apreciar el Diagrama de Objetos correspondiente.
Una Persona llamada Juan, tiene dos Motos, una con matrcula 108 y otra con la
matrcula 137. Adems, Juan, tiene un Auto con la matrcula 246.
per1 : Persona
nombre = Juan
: Moto
: Moto
: Auto
matricula = 108
matricula = 137
matricula = 246
Pgina 20 de 20
Anlisis de Sistemas
Diagrama de Secuencia
Este diagrama muestra un conjunto de objetos, sus relaciones y los mensajes que se
envan entre ellos. En l se destaca el orden temporal de los mensajes, por lo que se dice
que modela el aspecto dinmico del sistema.
Los Diagramas de Secuencias poseen las siguientes caractersticas:
Modelan la ejecucin de un caso de uso (escenario) al pasar el tiempo.

Se relaciona directamente a un escenario de un caso de uso. Para cada escenario
se confeccionar un diagrama de secuencias diferente. Comnmente, se
confecciona slo el diagrama de secuencia correspondiente al escenario exitoso.
Muestran el comportamiento interno del sistema, es decir, muestran los objetos que
participan.
Para confeccionarlo debe estar terminado el diagrama de clases y desarrollados los
casos de uso (no necesariamente refinados).
stos tipos de diagramas se crean durante el anlisis.
Se refinan durante el diseo para asignar mtodos y descripciones a las clases.
Se debe determinar qu clases del diagrama de clases son responsables de
participar en la resolucin del caso de uso.
Los diagramas de secuencias poseen lo que se llama Lneas de Vida, que se representa
como una lnea vertical discontinua y que implica la existencia de un objeto a lo largo de un
perodo de tiempo. Otra de las caractersticas que poseen es el Foco de Control
(activacin), el cual se representa como un rectngulo delgado, que implica el perodo de
tiempo durante el cual un objeto ejecuta una accin.
El eje horizontal se utiliza para los objetos y actores que forman parte del escenario del
caso de uso.
El orden de los objetos en el eje no importa.
Las interacciones entre actores y objetos del diagrama se representan con flechas
horizontales entre ellos.
Cada flecha puede contener la descripcin de la tarea que el actor u objeto origen realiza
sobre el objeto destino, las cuales, a medida que se vaya refinando el diagrama se irn
convirtiendo en el nombre de los mtodos.
objeto 1:Clase1
objeto 2:Clase2
Solicitud de tarea o actividad
Caractersticas del diagrama
Los objetos que existan antes de empezar la ejecucin del escenario se dibujan en
la parte superior del diagrama. Los objetos que son creados durante la ejecucin se
dibujan a la altura de su creacin en el eje del tiempo.
Los objetos que son eliminados durante la ejecucin del escenario se marcan con
una X y se finaliza su lnea de vida en ese mismo punto.
Pgina 21 de 21
Anlisis de Sistemas
Las flechas de respuesta se dibujan punteadas.

Para representar iteraciones una tarea se le pone un * delante del nombre. En
caso de que se desee iterar un grupo de tareas se encierran todas en un
rectngulo.
Ver Ejemplo 1.
Los diagramas de Secuencia contienen (en general) los siguientes elementos:
Objetos.
Mensajes.
Ejemplo 1:
En el siguiente ejemplo, se puede apreciar en forma genrica la nomenclatura de los
Diagramas de Secuencia.
Actor 1
objeto 1:Clase1
tarea 1
respuesta 1
tarea 3
respuesta 3
objeto 2:Clase2
tarea 2
respuesta 2
crear
objeto 3:Clase2
destruir
Pgina 22 de 22
Anlisis de Sistemas
Ejemplo 2:
En el siguiente ejemplo, se muestra el actor Cajero, que es quien debe contar la cantidad
de cuentas que tiene una determinada persona (a travs de su nmero de documento),
cuyo saldo supere un valor determinado. Para esto, ingresa el nmero de documento de la
persona y un valor de saldo. El objeto Control (sistema), busca al cliente. En esta
instancia es el Control quien realiza la bsqueda mencionada, ya que an no se sabe con
certeza a quien corresponde esa funcionalidad. A continuacin, se busca dentro del objeto
Cliente cada una de las cuentas que posee. Por cada una de ellas, se pedir al objeto
Cuenta el valor del saldo. Si el valor del saldo es superior al valor ingresado por el cajero
al inicio, se contar.
C:Control
Cli:Cliente
Cu:Cuenta
:Cajero
Ingresar N documento y valor
Buscar Cliente
Contar Cuentas
loop (Para cada cuenta)

Pedir Saldo
Saldo
[Saldo>valor]: Contar
Resultado (cantidad de cuentas)
Pgina 23 de 23
Anlisis de Sistemas
Diagrama de Colaboracin
Este diagrama muestra un conjunto de objetos y sus relaciones. Destaca la organizacin
estructural de los objetos que envan y reciben mensajes. Modela el aspecto dinmico del
sistema.
Los diagramas de Colaboracin contienen:
Objetos.
Enlaces.
Mensajes.
Los Diagramas de Colaboracin poseen las siguientes caractersticas:
Son una alternativa para los diagramas de secuencia. Se suelen utilizar ambos,
para validarse entre ellos.
Se crean en el anlisis y se los refina en el diseo.
Se genera un diagrama de colaboracin por caso de uso, mostrando todos los flujos
de ejecucin posibles (escenarios).
Caractersticas del diagrama
Para indicar las tareas, se utilizan flechas (enlaces con mensajes) entre los actores
y objetos y entre los objetos entre si.
Para indicar el orden temporal de un mensaje (tarea), se coloca un nmero
(comenzando con el mensaje 1, que se va incrementando por cada nuevo mensaje
(mensaje 2, mensaje 3, etc.).
No existen los mensajes de respuesta. Las mismas se expresan mediante la
asignacin a pseudo-variables.
Para representar anidamiento de las tareas (niveles de profundidad), se utilizan
nmeros. De esta manera, el 1 ser el primer mensaje, luego el 1.1 (primer
mensaje dentro del 1), luego vendr el 1.2 (segundo mensaje dentro del mensaje 1)
y as sucesivamente.
1:Mensaje (tarea 1)
objeto 1:Clase 1
Actor 1
Bifurcaciones
Las bifurcaciones en un diagrama de colaboracin tienen las siguientes caractersticas:
La condicin que hace que exista una bifurcacin se coloca entre corchetes junto al
nombre de la tarea.
A partir de la bifurcacin, se agregan letras a los nmeros de las tareas para indicar
los distintos caminos.
Si luego de la bifurcacin, los caminos se vuelven a juntar, se contina con la
numeracin original (sin letra).
Pgina 24 de 24
Anlisis de Sistemas
Iteraciones
Si una tarea o conjunto de tareas deben iterarse, se la marca con * y se pone la condicin
de fin entre corchetes. Los pasos que se realicen dentro de la iteracin deben iniciar una
sub-numeracin relativa al nmero de la iteracin.
4: tarea E
1: tarea A
objeto 1:Clase 1
2: tarea B
6: tarea G
objeto 3:Clase 3
Actor
5: [Cond 2] tarea
3a: [Cond 1] tarea C
3b: [NOT Cond 1] tarea D

objeto 4:Clase 3
objeto 5:Clase5
objeto 2:Clase 2
Diferencias entre el Diagrama de Secuencia y el de Colaboracin
La diferencia entre el diagrama de Secuencia y el de Colaboracin, son las siguientes:
El de Secuencia se utiliza para representar escenarios y el de Colaboracin se

utiliza para mostrar el flujo completo de un caso de uso.
Los diagramas de secuencia modelan las interacciones entre objetos al pasar el
tiempo, mientras que los diagramas de colaboracin pone nfasis en el pasaje de
informacin entre objetos.
Ejemplo:
En el siguiente ejemplo, se desea crear una Cuenta para un Cajero.
6: cuenta=Generar cuenta
4: Desplegar Datos
Solicitar importe
9: Guardar cuenta
2: Buscar Cliente
5: Ingresar importe
1: Ingresar documento
8: Asignar
C:Control
3: Pide datos
Cli:Cliente
Caj ero
7: Crear cuenta (cuenta, importe)
Cu:Cuenta
Pgina 25 de 25
Anlisis de Sistemas
Diagrama de Estados
Antes de describir que es un diagrama de Estados, se definirn algunos conceptos
Estado: es una condicin o situacin en la vida de un objeto. Se representan con un valo
que contiene el nombre del estado.
Evento: es la especificacin de un acontecimiento significativo, que se da en un
determinado momento. Es un estmulo que provoca que un objeto cambie de un estado a
otro.
Transicin: es una relacin entre dos estados que indica que un objeto que se encuentra
en un determinado estado pasar (luego de una accin) a otro estado distinto, habindose
cumplido ciertas condiciones y ocurrido determinado evento.
Accin: es una ejecucin que produce un cambio.
Este diagrama muestra un conjunto de estados, eventos y actividades. Se emplea para

visualizar, especificar, construir y documentar los aspectos dinmicos de un sistema. Se
centra en el estado cambiante del sistema y son tiles para modelar la vida de un objeto.
Un diagrama de Estados muestra una mquina de estado. Una mquina de estado, es un
comportamiento que especifica las secuencias de estados por las que pasa un objeto a lo
largo de su vida, en respuesta a eventos.
Los diagramas de Estados contienen (en general):
Estados Simples: es una condicin o situacin en la vida de un objeto.
Estados Compuestos: estado compuesto por subestados concurrentes.
Transiciones, eventos y acciones.
Los Diagramas de Estados poseen las siguientes caractersticas:
Muestran cmo un objeto cambia en el tiempo.

Se crean y refinan en la etapa de anlisis.
No muestran intercambio de informacin entre distintos objetos.
Pueden construirse tanto antes o despus de los diagramas de secuencia y
colaboracin.
Todo los objetos poseen un conjunto finito de estados.
La transicin entre estados, se representa con una flecha que une los dos estados
involucrados (origen y destino). A la flecha se le coloca un nombre con la
descripcin del evento que motiva el cambio de estado.
A travs de la ocurrencia de un evento se pueden generar varios estados posibles.
En estos casos, se puede especificar la condicin por la cual se pasa a un estado o
a otro.
Pgina 26 de 26
Anlisis de Sistemas
Ejemplo:
En el siguiente ejemplo, se muestran los posibles estados que puede tener una Cuenta
bancaria. En caso de que se retire un monto superior al del saldo que se posee, la Cuenta
pasar a estar en estado Sobregirada. Si se deposita un monto que sea mayor al del
valor negativo de la Cuenta, esta volver a estar en estado Crdito, caso contrario,
seguir estando en el estado Sobregirada.
Retiro
Depsito (Monto Depsito < Saldo negativo)
Retiro (Monto Retiro <= Saldo)
Apertura Cuenta
Crdito
Retiro (Monto Retiro > Saldo)
Sobregirada
Depsito (Monto Depsito > Saldo negativo)
Cerrar Cuenta
Final
Pgina 27 de 27
Anlisis de Sistemas
Diagrama de Actividades
Este diagrama muestran el flujo de actividades dentro de un sistema. Modela un aspecto
dinmico del sistema.
Es esencialmente un diagrama de flujo de actividades que tienen lugar a lo largo del
tiempo.
Cada actividad se considera indivisible.
Los Diagramas de Actividades poseen las siguientes caractersticas:
Se utilizan para modelar procesos y actividades.

Describen grficamente diferentes rumbos de ejecucin (alternativas) para una
actividad.
Permite modelar los diferentes flujos presentes en un caso de uso.
Estado Inicial: el punto de comienzo del diagrama.
Estado Final: el estado o punto en el que finaliza la flujo de actividades.
Bifurcacin (Decisin)
En base a una condicin determinada, se opta por un camino o por el otro. Expresa una
bifurcacin en el rumbo de la ejecucin.
[ TRUE ]
[ FALSE ]
Conjuncin
La ejecucin del flujo puede venir desde dos rumbos distintos, y continuar luego de la
conjuncin (sin importar por cul rumbo haya llegado hasta ella).
Fork
Cuando llega una tarea se divide en varios rumbos de ejecucin paralelos (no
necesariamente concurrentes, sino que pueden ocurrir en cualquier orden).
Join total
La ejecucin contina luego de que han llegado al join las diferentes ejecuciones (tareas)
en paralelo (no necesariamente concurrentes).
Pgina 28 de 28
Anlisis de Sistemas
Join parcial
Una vez que han llegado al join tantas ejecuciones en paralelo (no necesariamente
concurrentes) como se especifica, contina la ejecucin. No es necesario que lleguen
todos los rumbos para que la ejecucin contine luego del join.
Separadores
Permiten dividir secciones en el diagrama dependiendo de qu o quin est a cargo de

ejecutar los flujos correspondientes a cada seccin.
Ejemplo:
Fanti co
Si ste m a
Despliega Lis ta de CD
disponibles
Selecciona un CD de la
lis ta
Desplie ga temas CD,

Datos Artistas, Pre cio CD
Desea Com prar CD?
No
Si
Si
Desea Vol ver?
Solicita Nmero de tarj eta

crdito y direccin de
e ntre ga
No
Ingresa N de
tarj eta
Ingresa
Direccin
Valida Tarj eta
T arj eta apta?
No
Si
Imforma error en
tarj eta
Em ite mensaj e
confirmando
Si
Despliega fecha
estimada de
Desea i ngresar otro N m ero?
No
Pgina 29 de 29
Anlisis de Sistemas
Diagrama de Componentes
Este diagrama muestra la organizacin y las dependencias entre un conjunto de
componentes.
Un componente es una parte fsica del sistema. Es un conjunto de clases agrupadas
fsicamente juntas
en el momento de implementarlas.
stos diagramas, se utilizan para modelar la vista de implementacin esttica del sistema,
lo que significa, modelar los elementos fsicos (con sus relaciones), como ser las tablas,
archivos, documentos, etc.
Los diagramas de Componente contienen (en general):
Componentes.
Interfaces.
Relaciones.
Los diagramas de Componentes poseen las siguientes caractersticas:
Son la representacin grfica de la vista de implementacin esttica del sistema.

Permite modelar los elementos fsicos (tablas, archivos).
Se pueden dar tanto vistas privadas como pblicas.
Es posible indicar dependencias entre componentes.
Suelen construirse durante la fase de diseo.
Ejemplo:
El siguiente ejemplo de Componente, posee una vista pblica, ya que se puede apreciar
por qu clases u objetos est compuesto.
alumnos
ALUMNO
*
1
<<coleccin>>
ALUMNOS
MATERIA
*
1
<<coleccin>>
MATERIAS
Pgina 30 de 30
Anlisis de Sistemas
Diagrama de Deployment
Antes de describir que es un diagrama de despliegue, se definir el siguiente concepto,
necesario para su comprensin:
Nodo: elemento fsico que representa un recurso computacional, que puede tener
capacidad de procesamiento.
El Diagrama de Despliegue es un diagrama estructural que muestra un conjunto de nodos

y sus relaciones. stos tipos de diagramas aparecen cuando se modelan los aspectos
fsicos de los sistemas. Modela un aspecto esttico del sistema.
Los diagramas de Despliegue contienen (en general):
Nodos.
Relaciones.
Los Diagramas de Deployment poseen las siguientes caractersticas:
Son diagramas que permiten mostrar los distintos componentes fsicos involucrados
en el sistema (Pc, servidores, etc.).
Cada componente se representa mediante un cubo (Nodo).
Puede tener vista pblica como privada.
Pueden usarse para mostrar la integracin entre mltiples sistemas.
Ejemplo:
1..*
Cliente
Bedela
<< tcp >>
1
Servidor
Bedela
*
1
Impresora
de Red
DBMS
Las asociaciones se pueden etiquetar con, por ejemplo, los protocolos de comunicacin.
Adems, se pueden agregar las multiplicidades entre los nodos.
Pgina 31 de 31
Anlisis de Sistemas
Relaciones en UML
Tipo de Relacin
Asociacin
Grfico
Agregacin
Composicin
Herencia
Dependencia
Extensin
<<extend>>
Inclusin
<<Include>>
Descripcin
es un enlace (conexin) entre dos
o ms clases. Representa
relaciones entre instancias de
clases. En esta relacin no se
establece direccin (es
birideccional).
Es un tipo particular de asociacin.
Describe una relacin tiene un...
Se refiere al concepto de definir un
objeto en trminos de sus
componentes.
Es un tipo particular de asociacin.
Describe una relacin contiene...
Indica que un objeto no puede
existir sin contener a otro.
es una relacin entre un elemento
general (superclase o padre) y
un caso ms especfico de ese
elemento (subclase o hijo). El hijo
comparte la estructura y el
comportamiento del padre. De esta
manera, el hijo hereda las
propiedades de su padre (atributos
y operaciones). Por otra parte, el
hijo, puede aadir otros atributos y
operaciones, adems de los que
hereda.
cuando una clase depende de los
servicios de otra clase para
cumplimentar un servicio particular.
es una relacin que ampla la
funcionalidad de un Caso de Uso
mediante la extensin de sus
secuencias de acciones.
es una relacin mediante la cual se
reutiliza un Caso de Uso en
distintos contextos, a travs de su
invocacin desde otros casos de
uso.
Pgina 32 de 32
Anlisis de Sistemas
Caso Prctico
A continuacin se presenta un ejemplo, basado en un proyecto cierto, para llevar a cabo
una comparacin entre el paradigma orientado a objetos y el estructurado.
Se comenzar con una breve descripcin sobre la organizacin y el sistema involucrado,
luego se plantearn dos casos: Caso N1: Metodologa Orientada a Objetos y Caso N2:
Metodologa Estructurada.
Con esto, se busca mostrar cmo una misma situacin puede ser modelada a travs de
dos paradigmas diferentes.
Presentacin de la organizacin
La UTN, es una universidad pblica, gratuita y de carcter federal, consta de 21 Facultades
Regionales y 8 Unidades Acadmicas que cubren todas las regiones de la Argentina.
Esto se traduce en una permanente e ntima vinculacin con los sistemas productivos
regionales
y
un
fecundo
intercambio
acadmico
a
nivel
nacional.
Por otra parte, su extensin geogrfica se traduce en una capacidad de absorcin de
alumnado - 70.000 cursantes - que equivale a ms del 50 % de todos los estudiantes de
Ingeniera del pas.
Otra caracterstica, la UTN es la nica Universidad del pas cuya estructura acadmica
tiene
a
las
ingenieras
como
objetivo
prioritario.
En esta casa de estudios se dictan 15 carreras de grado y de ellas han egresado ms de
30.000 alumnos.
Se desea desarrollar un sistema de sufragio on-line (SOL) para las elecciones de
consejeros estudiantiles de la Universidad Tecnolgica Nacional y que funcione integrado
al sistema electoral actual, con el objetivo de agilizar todo lo incumbente al proceso
electoral de consejeros estudiantiles de la Universidad Tecnolgica Nacional, acelerar sus
tiempos de respuesta en el raconto de votos e imponer un marco de confiabilidad sobre el
mismo.
El sistema constar de una aplicacin Web para efectuar el voto virtual y una aplicacin
Visual Basic para el proceso de votacin manual y recuento de votos.
El sistema SOL debe permitir emitir un voto en forma remota previa identificacin del
votante, automatizar el sufragio de estos votos, integrar el sistema SOL con el sistema de
votacin manual pre-existente, consolidando los resultados de la eleccin en un marco de
absoluta seguridad.
Descripcin de usuarios
Existen 5 tipos de usuarios: los Sufragantes, Operadores, Autoridad de Mesa, Junta
Electora y Secretara Acadmica.
Los usuarios cuentan con roles y funciones asignados que determinan a qu capacidades
del sistema tienen acceso. Aquellas capacidades para las que no se les haya otorgado
acceso, no slo sern inaccesibles sino que tampoco sern visibles.
Tanto para el caso de votos manuales, como electrnicos, el sistema deber recibir de
Secretara Acadmica el Padrn Electoral con los datos de los alumnos que estn en
condiciones de votar. Como as tambin deber incorporar la Lista de Candidatos, por lo
que recibir la lista de candidatos que se presentan a elecciones de las
distintas
agrupaciones.
Recibir adems, el listado de todos los miembros que componen la Junta Electoral en las
respectivas elecciones.
Deber incorporar la lista de Alumnos de la facultad, que es brindada por Secretara
Acadmica.
Pgina 33 de 33
Anlisis de Sistemas
En base a toda esta informacin, se debern generar las listas de alumnos que no votaron,
los que debern ser penalizados.
Si el voto se va a efectuar va web, el usuario debe poder ingresar con su cdigo de
identificacin (PIN), su nmero de Legajo y podr efectuar su voto seleccionando sus
candidatos de la lista de candidatos en forma simple. A este usuario se le entregar un
comprobante de voto. Con todos los votos emitidos se genera un Registro de votos
electrnicos.
Cuando la Junta Electoral lo dispone, se proceder al cierre de la mesa, el sistema deber
realizar el recuento de los votos emitidos electrnicamente.
Con el Registros de votos electrnicos, los votos electrnicos sern interpretados por el
sistema y realizar la contabilizacin segn los valores contenidos en cada uno de ellos.
Se generar un listado con la contabilizacin de los votos electrnicos.
Si el voto se efecta manualmente, el sufragante se deber acercar al Anexo de la
Facultad correspondiente y deber presentar su nmero de legajo. Llevar a cabo su
votacin y se le entregar un comprobante de voto.
Cuando la Autoridad de la Mesa dispone cerrarla, se deber realizar, tambin el recuento
de votos emitidos manualmente. Se ingresarn los votos que fueron efectuados de forma
manuales. Este ingreso ser supervisado por 3 autoridades designadas por la junta
electoral, los cuales debern dar conformidad con los datos ingresados. Se generar un
listado con los resultados aprobados de la contabilizacin de los votos manuales
El sistema deber generar los resultados finales de la eleccin. En base a la
Contabilizacin de los votos electrnicos y los Resultados aprobados de la contabilizacin
de los votos manuales, la junta electoral comenzar a generar los resultados finales de las
elecciones.
Adems del total de votos por candidato, el sistema deber informar el porcentaje que
obtuvo cada una de las listas, porcentaje de los votos en la facultad regional, la cantidad de
personas que asistieron a sufragar, cortes de boleta, cantidad de votos impugnados y
cantidad de votos en blanco
Por ltimo, el sistema deber dar la facilidad de realizar consultas de inters, es decir, el
sistema permitir a los estudiantes consultar el padrn electoral (ingresando su nmero de
legajo), y los candidatos generales y de su especialidad. Adems, finalizado el proceso
eleccionario, podrn obtener de la pgina de la facultad todos los datos correspondientes a
los comicios, mostrndose todas las estadsticas del escrutinio, como as tambin
informacin adicional de los candidatos.
Pgina 34 de 34
Anlisis de Sistemas
Caso N1: Metodologa Orientada a Objetos

En primer lugar se modelarn todos los actores definidos en el sistema y sus relaciones.
Diagrama de Actores
Pgina 35 de 35
Anlisis de Sistemas
A continuacin se llevarn a cabo los casos de uso correspondientes al sistema.

Pgina 36 de 36
Anlisis de Sistemas
Documentacin de Casos de Uso

A continuacin se muestra a modo de ejemplo, la documentacin de alguno de los casos
de uso realizados.
Caso de Uso
Actores
Descripcin
Votar va Web.
Sufragante.
El usuario emite su voto a travs de la pgina web de la
Universidad.
Precondicin
Flujo Principal
Flujo Alternativo / Excepciones
1 El Sufragante ingresa su nmero de

legajo y PIN.
2 El sistema valida que el Legajo y
PIN sean vlidos.
2.a - El sistema no autoriza al

sufragante, deniega el acceso y emite
un mensaje de error.
3 El sistema autoriza al usuario.

4 El sufragante selecciona los
candidatos deseados y efecta el
voto.
5 El sistema procesa el voto y emite
un comprobante de voto.
Observaciones
Postcondicin
Voto efectuado.
Emisin de comprobante de voto.
Pgina 37 de 37
Anlisis de Sistemas
Caso de Uso
Actores
Descripcin
Precondicin
Flujo Principal
Cerrar Mesa Virtual.

Junta Electoral.
Recibir la solicitud de la Junta Electoral para realizar el cierre
de mesa virtual.
Debe haber iniciado el cierre de sufragio.
Flujo Alternativo / Excepciones
1 La Junta Electoral solicita al sistema

el cierre de mesa virtual.
2 El sistema verifica que la Mesa
virtual pueda cerrarse.
2.a.- La mesa virtual no puede cerrarse

en ese momento.
3 El sistema realiza el cierre de Mesa

virtual.
4 El sistema realiza el recuento de
votos virtuales.
5 La instancia del caso de uso finaliza.
Observaciones
Postcondicin
Votos virtuales contados.

Mesa virtual cerrada, no se pueden emitir mas votos virtuales.
Pgina 38 de 38
Anlisis de Sistemas
Para la modelizacin de este sistema se llevarn a cabo los diagramas de secuencia

correspondientes a las especificaciones de caso de uso anteriores, en forma general.
Tener en cuenta que luego stos diagramas se irn refinando.
Votar Va Web
Cerrar Mesa Electoral
Pgina 39 de 39
Anlisis de Sistemas
A continuacin se detalla el Diagrama de Clases.
Pgina 40 de 40
Anlisis de Sistemas
Caso N2: Metodologa Estructurada

Diagrama de Contexto
Visitante
Consulta
Legajo
Usuario
PIN
Respuesta
Rta.Autenticacin
Sistema
Sufragio
On Line
Padrn
Secretara
Acadmica
Candidatos
Agrupacin
Cierre Mesa
Legajo
Autoridad
Mesa
PIN
Cantidad Sufragantes
VotosxCandidato
Voto Emitido
Sufragante
Tipos de Votos
porc x lista
Cierre Mesa
Junta
Electoral
Pgina 41 de 41
Anlisis de Sistemas
Diagrama de Flujo de Datos
Visitante
Legajo
Usuario
Autentificar
Usuario
PIN
Usuarios Autenticados
D2 User Autent.
Consulta
Usuarios Autenticados
Gestionar
Consultas
W eb
Respuesta
Rta.Autenticacin
D1 Candidatos
Gestionar
Voto
Manual
Gestionar
Voto
Electrnico
Miembros Junta
Legajo
Miembros Junta
Voto Manual
Miembros Junta
Voto Emitido
Sufragante
D4
Miembros Junta
Junta
Electoral
D3
Padrn
Junta
Electoral
Padrn
Padrn
Candidatos
Candidatos
Secretara
Acadmica
Padrn
D4
Padrn
Electoral
Secretara
Acadmica
Candidatos
D3
Agrupacin
Padrn
Electoral
Padrn
Voto Emitido
Votos Electrnicos
PIN
Sufragante
D7
D5
Votos
Manuales
Votos
Electrnicos
Autoridad
Mesa
Voto Manual
Junta
Electoral
porc x lista
Cierre Mesa
Votos Electrnicos
Cierre Mesa
Contar
Votos
Electrnicos
Listado Votos
Electrnicos
Listado Votos
Manuales
Listado
Votos Man
Contar
Votos
Manuales
D8
Junta
Electoral
Tipos de Votos
D6
Listado
Votos Electr
Pgina 42 de 42
Listado Votos Electrnicos
VotosxCandidato
Listado Votos
Manuales
Cantidad Sufragantes
Generar
Resultado
Final
Anlisis de Sistemas
Anexo 1: Plantilla Caso de Uso
Caso de Uso
Actores
Descripcin
Precondicin
Curso Normal
Alternativo / Excepciones
Observaciones
Postcondicin
Pgina 43 de 43
Anlisis de Sistemas
Glosario
Abstraccin: se ignoran detalles para centrarse en caractersticas esenciales. Permite
simplificar la informacin acerca del objeto.
Acoplamiento: indica el nivel de dependencia entre objetos.
Actor: representa un conjunto de roles que los usuarios de los casos de uso juegan al
interactuar con ellos.
Agregacin: es un tipo particular de asociacin. Describe una relacin tiene un...
Se refiere al concepto de definir un objeto en trminos de sus componentes.
Asociacin: forma de interaccin entre objetos. Dos objetos estn asociados cuando uno
usa servicios u operaciones brindados por el otro.
Caso de Uso: descripcin de un conjunto de secuencias de acciones que ejecuta un
sistema para obtener un resultado, el cual es de valor para un actor.
Clase: describe un conjunto de objetos que tienen en comn los mismos atributos,
operaciones, relaciones y semntica.
Cohesin: es el grado de relacin entre clases en relacin a un propsito dentro del
sistema.
Componente: es una parte fsica del sistema.
Composicin: es un tipo particular de asociacin. Describe una relacin contiene...
Indica que un objeto no puede existir sin contener a otro.
Diagrama de Actividad: muestran el flujo de actividades dentro de un sistema. Es
esencialmente un diagrama de flujo de actividades que tienen lugar a lo largo del tiempo.
Modela un aspecto dinmico del sistema.
Diagrama de Casos de Uso: diagrama que muestra un conjunto de casos de uso, actores
y sus relaciones. Se utilizan para visualizar el comportamiento de un sistema o un
subsistema.
Diagrama de Clases: describe las clases que se deben crear en el sistema junto con las
relaciones existentes entre ellas. Representa el modelo esttico del sistema.
Diagrama de Colaboracin: muestra un conjunto de objetos y sus relaciones. Destaca la
organizacin estructural de los objetos que envan y reciben mensajes. Modela el aspecto
dinmico del sistema.
Diagrama de Componentes: muestra la organizacin y las dependencias entre un
conjunto de componentes. Es un conjunto de clases agrupadas fsicamente juntas en el
momento de implementarlas. Modelan la vista de implementacin esttica del sistema.
Diagrama de Deployment (Distribucin): es un diagrama estructural que muestra un
conjunto de nodos y sus relaciones. stos tipos de diagramas aparecen cuando se
modelan los aspectos fsicos de los sistemas. Modela un aspecto esttico del sistema.
Pgina 44 de 44
Anlisis de Sistemas
Diagrama de Estado: muestra un conjunto de estados, eventos y actividades. Permite

visualizar cmo un objeto pasa de un estado a otro, por medio de la ejecucin de un
determinado evento. Permite modelar aspectos dinmicos de un sistema.
Diagrama de Objetos: muestra un conjunto de objetos junto a sus relaciones. Representa
el aspecto esttico del sistema y se lo puede considerar como una foto del diagrama de
clases en un momento dado.
Diagrama de Secuencia: muestra un conjunto de objetos, sus relaciones y los mensajes
que se envan entre ellos. En l se destaca el orden temporal de los mensajes. Pertenece
al modelo dinmico del sistema.
Encapsulamiento:
Los datos estn escondidos dentro del objeto. Permite determinar qu informacin es
publicada y qu informacin es ocultada al resto de los objetos. Para ello los objetos suelen
presentar sus mtodos como interfaces pblicas y sus atributos como datos privados,
quedando de esta manera inaccesibles desde otros objetos.
Evento: es un suceso que requiere una respuesta del sistema. Puede ser originado por el
contexto o por condiciones de tiempo.
Flujo Alternativo: es una desviacin del curso normal del caso de uso. Representa un
error o excepcin en el curso normal del caso de uso.
Flujo de Eventos: secuencia de pasos por los que atraviesa un caso de uso.
Flujo Principal: secuencia de pasos del curso normal del caso de uso.
Glosario: Documento en el cual se identifican los trminos comunes del dominio del
problema (propios del sistema).
Herencia:
Permite definir una nueva clase en trminos de otra clase ya existente. Describe una
relacin es un ...
Modelo: representacin simplificada de la realidad.
Nodo: elemento fsico que representa un recurso computacional, que puede tener
capacidad de procesamiento.
Objeto: es una unidad atmica que posee un estado y un comportamiento. El estado est
determinado por el valor que toman los atributos del objeto en un instante dado. Un objeto
representa una entidad fsica, o bien una entidad abstracta.
Polimorfismo:
Mecanismo basado en herencia. Permite redefinir una misma operacin para dos o ms
clases relacionadas mediante herencia.
El comportamiento de una operacin polimrfica depende del objeto en concreto sobre la
cual es aplicada.
Postcondiciones: estado en el que queda el sistema y su entorno luego de la ejecucin
del caso de uso.
Precondiciones: estado en el que debe estar el sistema y su entorno para que pueda
comenzar la ejecucin del caso de uso.
Pgina 45 de 45
Anlisis de Sistemas
Requisitos: condicin o caracterstica que debe tener o cumplir un sistema o componente

de un sistema para satisfacer un contrato, norma, especificacin u otro documento
formalmente impuesto.
Relacin Extend (Extensin): relacin a travs de la cual un caso de uso incorpora
implcitamente y bajo ciertas condicione (opcionalmente) el comportamiento del otro caso
de uso.
Relacin Include (Inclusin): relacin a travs de la cual un caso de uso incorpora el
comportamiento de otro caso de uso. Se usa para evitar describir el mismo flujo de eventos
repetidas veces, poniendo el comportamiento comn en un caso de uso aparte.
Usuario: persona que interacta directamente con el sistema.
Pgina 46 de 46
Anlisis de Sistemas
Bibliografa
El Lenguaje Unificado de Modelado G. Booch, J. Rumbaugh, I. Jacobson.

Editorial: Addison Wesley 2000.
Slo programadores Linux Editorial: AEPP - Ao IV - 2001
Apuntes Ctedra Diseo de Sistemas UTN.
Proyecto SOL Ramiro Garbarini - 2002
Pgina 47 de 47

Apunte MOO 2007

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apunte MOO 2007

Cargado por

Copyright:

Formatos disponibles

Anlisis de Sistemas

Metodologa Orientada a Objetos

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Porque no se pueden comprender los sistemas en su totalidad, cuando stos son

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Tcnica de Modelado de Objetos (OMT)

Conceptos bsicos de Orientacin a Objetos

Metodologa Orientada a Objetos

Es deseable tener bajo acoplamiento y alta cohesin.

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Diferencias entre la metodologa orientada a objetos y los mtodos

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Breve historia de UML

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Diagrama de Casos de Uso

Estn expresados desde el punto de vista del actor.

Utilidad de los Casos de Uso

Para modelar el contexto de un sistema.

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Documentacin de Casos de Uso

Relaciones de Extensin y de Inclusin

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Diagrama de Casos de Uso

Nota: Para obtener ms informacin leer Apunte: Casos de Uso de la ctedra.

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Metodologa Orientada a Objetos

El comportamiento de los mtodos no se define en la etapa de anlisis.

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Metodologa Orientada a Objetos

Los tipos de multiplicidades que se presentan son los siguientes:

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Relaciones entre objetos

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Los diagramas de Objetos contienen (en general), los siguientes elementos:

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Modelan la ejecucin de un caso de uso (escenario) al pasar el tiempo.

Solicitud de tarea o actividad

Caractersticas del diagrama

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

Las flechas de respuesta se dibujan punteadas.

UTN-Universidad Tecnolgica Nacional

Metodologa Orientada a Objetos

loop (Para cada cuenta)