Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Manual Análisis y Diseño Orientado A Objeto Versión 1.2
Manual Análisis y Diseño Orientado A Objeto Versión 1.2
de
las
carreras
del
rea
informtica.
Queda
Pgina 1 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Agradecimientos.
Agradecemos a todas las personas que de forma directa o indirecta
han colaborado en la elaboracin de este manual.
De forma significativa agradecemos a los docentes de las sedes que
nos han apoyado y colaborado con ejercicios y propuestas durante
la presentacin de este proyecto.
Vayan nuestros sinceros agradecimientos a los siguientes docentes:
Cristian Leiva Marn, Miguel Palma Esquivel, Marcelo Montecinos
Cabrera, Rodrigo Toledo de los Santos, Paola Cifuentes
Berrios,
Pgina 2 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 3 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
ndice
Introduccin al anlisis y diseo Orientado a Objetos .............................................................................................8
Definicin del anlisis y diseo orientado a objetos ......................................................................................... 11
Importancia del anlisis y diseo orientado a objetos ...................................................................................... 11
Diferentes metodologas de anlisis de sistemas.............................................................................................. 12
Los datos, la informacin y su importancia para las organizaciones. ............................................................... 18
Definicin de los datos en el contexto de un problema.................................................................................... 20
Teora de sistemas bsica y la interaccin de los objetos en una organizacin................................................ 24
Patrn ECB (Entity Control Boundary) ......................................................................................................... 27
Datos, comportamiento y relaciones de los objetos. ........................................................................................ 31
Definicin de UML ............................................................................................................................................. 36
Etapas del ciclo de vida utilizando RUP (Rational Unified Process) .................................................................. 37
Diagramas de Estructura. .................................................................................................................................. 41
Diagrama de clases ........................................................................................................................................ 41
Diagrama de objeto ....................................................................................................................................... 49
Diagrama de estructuras compuestas. .......................................................................................................... 52
Diagramas de componentes. ......................................................................................................................... 54
Diagrama de despliegue. ............................................................................................................................... 57
Diagrama de paquete. ................................................................................................................................... 59
Diagramas de comportamiento......................................................................................................................... 61
Diagrama de casos de uso. ............................................................................................................................ 61
Diagrama de mquina de estados. ................................................................................................................ 64
Diagrama de actividad. .................................................................................................................................. 66
Diagramas de Interaccin. ................................................................................................................................. 68
Diagrama de secuencias. ............................................................................................................................... 68
Diagrama de tiempo. ..................................................................................................................................... 71
Tcnicas de recopilacin y anlisis de requerimientos. ........................................................................................ 75
Tcnicas de captura de requerimientos. ........................................................................................................... 75
Entrevista. ...................................................................................................................................................... 79
Pgina 4 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Encuesta. ....................................................................................................................................................... 79
Observacin directa....................................................................................................................................... 80
Definicin de actividades................................................................................................................................... 80
Relacin entre las actividades y los actores. ..................................................................................................... 82
Anlisis bsico de los requerimientos para la realizacin de un listado de actividades. .................................. 83
Diagrama de flujo de datos (Agile Unified Process). ......................................................................................... 85
Diagrama de procesos (BPMN 2.0) .................................................................................................................... 91
Diagrama de casos de uso. .................................................................................................................................. 100
Componentes del diagrama de casos de uso. ................................................................................................. 103
Actores. ........................................................................................................................................................ 105
Casos de uso. ............................................................................................................................................... 106
Relaciones. ................................................................................................................................................... 110
Identificacin del contexto en el que participan los actores. ......................................................................... 113
Identificacin de los roles. ............................................................................................................................... 114
Definicin de los actores. ................................................................................................................................ 115
Definicin de los casos de uso. ........................................................................................................................ 116
Definicin de los casos de uso. ........................................................................................................................ 117
Definicin de los tipos de relaciones ............................................................................................................... 119
Comunicacin. ............................................................................................................................................. 119
Inclusin....................................................................................................................................................... 119
Extensin. .................................................................................................................................................... 120
Generalizacin. ............................................................................................................................................ 121
Documentacin de los casos de uso................................................................................................................ 121
Definicin del caso de uso. .............................................................................................................................. 122
Flujo Normal. ................................................................................................................................................... 122
Pre-condiciones. .............................................................................................................................................. 123
Post-condiciones. ............................................................................................................................................ 123
Diagrama esttico de clases. ............................................................................................................................... 126
Introduccin al diagrama esttico de clases. .................................................................................................. 126
Utilidad del diagrama esttico de clases. .................................................................................................... 127
Componentes del diagrama esttico de clases. .......................................................................................... 128
Pgina 5 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Relacin entre las clases y las tablas de un modelo entidad relacin............................................................. 138
Componentes del diagrama esttico de clases. .............................................................................................. 139
Relaciones entre las clases. ............................................................................................................................. 144
Asociacin. ................................................................................................................................................... 146
Multiplicidad. ............................................................................................................................................... 148
Asociacin calificativa. ................................................................................................................................. 149
Asociacin reflexiva. .................................................................................................................................... 150
Herencia....................................................................................................................................................... 151
Asociacin. ................................................................................................................................................... 151
Realizacin. .................................................................................................................................................. 154
Pgina 6 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 7 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 8 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
decisiones,
mientras
ms
comprendemos
menos
deberemos memorizar.
El primer paso consiste en hacer anlisis, entender el problema de
tu cliente e identificar una buena solucin. El segundo paso ser
disearla, el paso previo a construirla. Muchos software comienzan
a ser codificados sin un buen anlisis, lo que da como resultado un
producto deficiente que no soluciona el problema del cliente. Un
mal diseo provocara un software con errores en el cual se habr
trabajado probablemente el doble de lo necesario, los errores en
diseo comienzan notarse tarde en el desarrollo haciendo que una
gran cantidad de programas queden en el 90% de su construccin,
haciendo que el 10% restante implique incluso ms trabajo que el
90% anterior. Para que te hagas una idea esto no es algo que no
pase en el resto de las disciplinas, has pensado en cmo quedara
un edificio si la constructora comienza su tarea sin un anlisis y
diseo apropiado? y si lo logra, soportar el prximo temblor?
Ahora pensemos en qu sucede si el diseo es apropiado, pero
proviene de un mal anlisis de requerimiento y si bien el edificio
queda bonito con 80 pisos, grandes ventanales y piscina en la
azotea, pero despus de construido y luego de una larga y
pausada conversacin con tu cliente en la cual te tomas ms
tiempo para entenderlo, haces un mejor anlisis y te das cuenta
que lo que en realidad necesitaba era un bunker subterrneo para
sobrevivir al paso de un tornado. A estas alturas ya no hay nada
que hacer, desarmar el edificio, para dejar el terreno libre para
luego comenzar a disear y construir un bunker llevar sin duda a
tu empresa a un fracaso, deja a tus clientes sin un bunker y a t en
Pgina 9 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 10 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
habilidades,
conocimientos
cuidados
especficos.
bsicas,
una
metodologa
estructurada
una
http://es.wikipedia.org/wiki/Metodolog%C3%ADa
Pgina 13 de 154
desarrollo
de
proyectos
de
tecnologas
de
informacin
aplican
durante
las
etapas
de
anlisis,
construccin
y sus
necesario interactuar con los usuarios del sistema (los que realizan
las acciones) para identificar sus necesidades y analizar el sistema
para entender su funcionalidad.
Basndose en el sistema estudiado, se prepara un modelo del
sistema definido. Este modelo est basado puramente en lo que se
requiere que el sistema haga. En esta etapa los detalles de
implementacin (como se van a hacer las cosas) no son tomados
en cuenta. Slo se prepara un modelo del sistema basndose en la
idea de que el sistema es un conjunto de objetos que interactan.
La etapa de diseo del sistema es la siguiente etapa de desarrollo
dnde se decide la arquitectura del modelo completo (hardware y
software). Este sistema complejo es organizado en un conjunto de
sub procesos, cada uno con su proyecto individual, los cuales van
a interactuar unos con otros. Mientras se disea el sistema, es
necesario poner especial atencin a las especificaciones de los
procesos definidos en la etapa anterior por parte de los usuarios.
Como el anlisis orientado a objetos percibe los sistemas como un
conjunto de objetos que interactan, as mismo los sistemas ms
grandes y complejos se pueden ver como un conjunto de pequeos
sistemas que interactan entre s.
En la etapa de diseo de los objetos, se definen los detalles del
anlisis del sistema y del diseo para definir cmo sern
implementados. Ac se decide la forma en la que se van a
construir los objetos de manera de implementar las estructuras de
datos, los comportamientos y las relaciones entre cada uno de los
objetos.
Pgina 15 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
al
funcionamiento
del
software
(hardware
Comparada
con
las
tcnicas
de
desarrollo
de
sistemas
Los
sistemas
diseados
utilizando
este
enfoque
estn
ms
un
objeto
alumnos
ser
un
objeto
alumno
Pgina 17 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
diseos
realizados
con
esta
metodologa
enfatizan
la
natural,
esto
entrega
mejores
estructuras
para
el
Pgina 19 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 21 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 22 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
http://es.wikipedia.org/wiki/Jeanne_Calment
Pgina 23 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Entrada
Salida
Sistema 1
Medio ambiente
Sistema 2
Pgina 24 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
en
el
medio
ambiente
el
cual
es
equilibrado
(membrana,
ncleo,
citoplasma).
Ahora,
si
Pgina 25 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
consiste
en
aplicar
esta
teora
de
sistemas
Pgina 26 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
3
4
Pgina 27 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
que
vienen
definidos
desde
la
frontera.
La
Se opt por mantener el nombre del patrn tal cual como fue definido para evitar la confusin al leer otros apuntes.
Pgina 28 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 29 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Fjate que slo analizamos las funciones bsicas del cajero (sacar
plata, solicitar el saldo, transferir fondos), pero qu pasa si
adems necesitamos realizar un depsito en efectivo?, en ese caso
el modelo cambia un poco y entran otras entidades y procesos a
jugar.
Pgina 30 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
1) 22 jugadores
2) Pelota
3) Marcador
4) arbitro
Si sumamos obtendremos que: 22 jugadores + una pelota + un
marcador + un arbitro dan un total de 25 objetos, si bien la suma
esta correcta, el anlisis que debemos realizar durante esta
asignatura es ms simple, ya que 22 jugadores es slo la cantidad
Pgina 32 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Nombre
Posicin
Goles anotados
Pases dados
Recuperaciones
Pelota
Marca
Marcador
Arbitro
Nacionalidad
Jugador
Dar pase
Hacer gol
Recuperar el baln
Rodar
Rebotar
Pelota
Arbitro
Iniciar partido
Finalizar partido
Marcador
Definicin de UML
UML, cuya sigla significa lenguaje unificado de modelado, es un
lenguaje visual (basado en diagramas), que nos sirve para
visualizar y documentar el software que deseamos construir y
colaborar con la documentacin de todo el conocimiento de los
sistemas que deseamos construir, existen en UML distintos tipos
de diagramas, el objetivo de cada uno de ellos es presentar de
distintos puntos de vista una parte de un sistema, esto quiere
decir que por ejemplo una misma situacin puede ser diagramada
(dibujada) varias veces y con ms de un tipo de diagrama, donde
cada uno de ellos nos entrega un enfoque de la misma situacin
pero resaltando factores como el tiempo o el orden en el que
ocurren,
sin
embargo
uno
de
los
mayores
beneficios
es
construir.
La
vista
dinmica
en
cambio
modela
el
Fase de inicio
Fase de elaboracin
Fase de construccin
Fase de transicin
Pgina 37 de 154
con
los
planes
de
la
organizacin,
que
se
haya
Se entiende por contexto del negocio al contexto del problema a analizar, se trata de una actividad cualquiera que no
necesariamente tiene lucro de por medio.
Pgina 38 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
adicional
de
requerimientos
funcionales
no
al
producto,
todas
las
caractersticas
de
Diagramas de Estructura.
Diagrama de clases
En el paradigma de programacin orientada a objeto (POO) todos
los componentes de un software son llamados objetos,
por
conjunto
de
caractersticas
(atributos),
estados
como clase, donde tendremos que crear una clase para cada
objeto que deseamos construir, al conjunto de todas las clases se
le denomina diagrama de clases.
Una vez todas las clases han sido construidas debemos proseguir
con el paso nmero dos, el cual identificamos las asociaciones que
existen entre ellos, por ejemplo, en el ejemplo anterior una
asignatura puede contener de cero a muchos cursos (o secciones)
y cada curso puede tener entre 15 (el mnimo) y hasta 34 (el
mximo) alumnos, a su vez un alumno puede tener desde 3 a 8
notas, de aqu se desprenden dos conceptos, el primero llamado
asociacin que es la vinculacin de dos o ms clases y la
multiplicidad, que dice con cuantos objetos se asociar.
Pgina 41 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
que
existen
entre
las
clases
que
lo
componen,
esttica,
ms
adelante
veremos
que
una
vez
construido el objeto auto ste podr tener una rueda, dos o todas
si se las instalan y es en este momento en que la relacin se
vuelve realidad, pero fue posible slo debido a que nuestro
diagrama de clases nos guo para que pudisemos construir un
objeto con la capacidad de poder contener entre 0 y 4 ruedas.
Pgina 42 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 44 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
ms
adelante
utilizando
algn
lenguaje
de
Asociaciones.
Un diagrama se dice que presenta las relaciones estticas entre las
clases con el fin de establecer qu clases se relacionarn y cual
ser su multiplicidad, en el caso anterior por ejemplo, el vehculo
no es lo nico que debemos considerar para que podamos decir
que construimos un software que permita gestionar una carrera,
as tambin tendremos que crear la clase pista con sus respectivos
atributos y comportamientos siguiendo la misma tcnica anterior,
pero si construyo ambos objetos a partir de estas clases serviran
por separado?, pues no si lo queremos realizar es una carrera, es
Pgina 45 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 46 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Multiplicidad.
Uno a uno: esta relacin se da cuando dos instancias de una clase
tiene una asociacin de uno es a uno en ambos sentidos, un buen
ejemplo es el matrimonio, en el que un hombre se asocia a una
sola mujer y una mujer a un solo hombre, variables como el
divorcio, no interfieren con este ejemplo, debes tener presente que
un diagrama de clases es una foto de un momento, no de lo que
puede hacer un hombre o mujer a lo largo de su vida.
Pgina 47 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 48 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Diagrama de objeto
Los diagramas de objetos son similares en su anotacin al de
diagrama de clases y son un complemento que se utiliza para
enfatizar la relacin que existe entre dos instancias de clases en un
momento especfico de tiempo, la diferencia de este diagrama es
que no se presenta como una relacin esttica con su respectiva
multiplicidad, a cambio, muestra cmo un objeto se relaciona con
otros objetos luego de haberse construido, es decir un ejemplo de
cmo se ver en el futuro en algn instante de su vida, recuerdas
el ejemplo del vehculo y su relacin esttica con una posible
cantidad de cero a cuatro ruedas?, podramos realizar un ejemplo
de la relacin con sus ruedas, pero para eso debemos tener
objetos de tipo vehculo y algunas ruedas, as que el primer paso
ser construir un objeto de tipo vehculo segn lo que definimos en
nuestra clase, por si no lo recuerdas en ella especificamos que un
vehculo tendra un color, una marca y un modelo, no te preocupes
si no sabes como armar un auto por que no lo vas a necesitar, en
informtica un objeto es slo una agrupacin de informacin y
acciones que se pueden realizar con ella, debido a esto se
considera un objeto a una agrupacin de valores dados a cada una
de los atributos definidos en el diagrama de clases, por ejemplo si
construimos un objeto auto de tipo vehculo bastar con darle un
nombre, el cual podra ser miObjetoAuto, un valor para el atributo
color, que te parece rojo, una marca, le pondremos Ford,
al
Pgina 51 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
motor ni
Pgina 53 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Diagramas de componentes.
El diagrama de componentes es un diagrama de alto nivel de
abstraccin, en l van modelados todos los
(elementos)
que
componen
un
software.
En
componentes
l
vamos
ver piezas sueltas que parecen no tener una conexin entre s, sin
embargo en la mayora de los puzzles en la tapa de la caja traen
una
vista
del
puzzle
armado
podras
armarlo
sin
eso?
siguiente
dibujo
muestra
cmo
debe
representarse
un
componente.
Diagrama de despliegue.
El diagrama de despliegue es un diagrama que permite mostrar la
relacin fsica que tendrn los componentes de software y
hardware de un sistema, la mayora de los programas de hoy
estn distribuidos en ms de un computador, un buen ejemplo es
el Windows Live Messenger o Gtalk, estos software presentan ante
el usuario una ventana para que stos puedan escribir un mensaje
y enviarlo a otros usuarios, pero has pensado que sucede al
presionar el botn enviar?, pues al hacerlo los datos son tomados
y son enviados a otra aplicacin, la cual posiblemente est incluso
en otro pas, este software es el encargado por medio de una
interfaz de recibir tu mensaje, ubicar al destinatario y envirselo
para que lo pueda leer. Como puedes ver la aplicacin que instalas
en tu computador de poco servira sin la otra, la cual es la que
hace posible que cientos de miles de personas se comuniquen, ese
equipo que presta el servicio de comunicar se le denomina
Pgina 57 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 58 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Diagrama de paquete.
El diagrama de paquete sirve para formar una mejor visin de qu
queremos construir, para ello lo divide en subsistemas ms
pequeos, la agrupacin de los elementos se define en funcin de
algo que ellos tengan en comn y que los identifique como grupo,
para luego mediante flechas representar la dependencia que existe
entre ellos, es decir los elementos de un grupo que dependen de
otro que se encuentran en un grupo distinto, esto se hace para dar
orden y claridad en el diagrama, de esta forma evitamos tener
ciclos dentro de nuestra estructura, conoces el dilema de si es
primero la gallina o el huevo?, pues casos similares a estos
tambin se dan en el software, la dependencia es un tema que hay
que tomar muy en serio a la hora de construir un programa, un
error de dependencia de software sera el equivalente a tratar de
hacer una vela en una caverna sin luz, donde para realizarla
necesitas luz, pero para generar luz necesitas la vela, como
puedes ver hay una dependencia mutua que hace imposible que
podamos generar la luz necesaria, en el software esto tambin se
da: imaginemos que estamos en un lugar donde arriendan internet
y en cada equipo hay una aplicacin que bloquea el teclado cuando
recibe la orden desde el computador del encargado del lugar,
adicionalmente para que los usuarios no puedan engaar al
sistema y piensen en apagar y encender el equipo el software para
iniciar tiene un componente que busca en la red si el equipo del
operario esta activo para regular el uso, de no ser as el sistema no
permite usar el equipo y lo apaga, por otra parte el sistema del
operario tiene un componente que se encarga de verificar cules
computadores estn funcionado en la red para que puedan ser
gestionados, pero si no encuentra ninguno la aplicacin se cierra.
Pgina 59 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 60 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Diagramas de comportamiento.
Diagrama de casos de uso.
Este tipo de diagramas es esencialmente til durante la etapa de
anlisis, es decir cuando estas comenzado a entender lo que
necesita construir tu cliente, ya que su finalidad es describir los
actores que interactan con el software y los procesos que deben
realizar. Un actor se considera a cualquier elemento que interacta
con tu programa, que pueden ir desde otros software, un robot o
humanos, el caso de uso se refiere a todas las acciones que tu
software realizar, por ejemplo si estas considerando realizar un
software que simule una agenda entonces tendrs un solo actor,
(el encargado de agregar informacin a la agenda) y los procesos
o casos de uso que realizar sern, agregar un contacto, agregar
una actividad a realizar, ver las actividades pendientes, verificar
los datos de un contacto previamente agregado, etc. De todas
estas acciones no es necesario tener con toda claridad
toda la
Pgina 61 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Actor1
Pgina 62 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Agregar Contacto
Actor1
Buscar contacto
Pgina 63 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
tu
mismo
concentrado, etc.
tienes
varios
estados:
alegre,
triste,
diagrama
presenta
el
estado
inicial
del
objeto
va
Pgina 65 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Diagrama de actividad.
Este diagrama es muy similar al diagrama de mquinas de estado,
la diferencia principal es que en el diagrama de actividad no
muestra los estados de los objetos si no que modela cmputos y
flujos de trabajo, especificando el orden en el que se llevan a cabo,
adems se asume que no existen interrupciones externas para
dichos flujos, de ser as ser mejor modelar utilizando el diagrama
de maquina de estados visto previamente.
Pgina 66 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
actividad,
cada
una
va
inicindose
conforme
va
Pgina 67 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Diagramas de Interaccin.
Diagrama de secuencias.
El diagrama de secuencia es un diagrama que muestra la forma en
la que interactan los objetos dentro de un software agregando el
factor tiempo, de esta forma se puede visualizar el orden en el que
se ejecutan las llamadas en forma ordenada a partir de una
peticin, la mayora de las veces con un diagrama de caso de uso
es suficiente para comprender como interactan las partes, sin
embargo hay algunos casos en los que el proceso puede ser ms
complejo o requiera una explicacin mayor, es por ello que el
diagrama de secuencias viene casi siempre a partir de un caso de
uso especifico.
Pgina 68 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
necesario.
Veamos
con
un
ejemplo
que
representa
la
en
actividad,
sin
embargo
el
cliente
queda
con
la
Diagrama de tiempo.
Este diagrama permite mostrar el cambio de estado o valor de los
elementos a travs del tiempo, prcticamente todos los objetos
durante su vida van cambiando sus valores o estados y muchas
veces estos cambios son producidos por factor que tiene relacin
con el tiempo, antes de continuar es bueno aclarar que el estado
la mayora de las veces tambin produce un cambio en el
valor del objeto, por ejemplo, si tienes un termmetro digital,
Pgina 71 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
de
una
lavadora,
ya
que,
las
lavadoras
para
diagramar
esto,
utilizaremos
un
grafico
con
Pgina 72 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 73 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 74 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Tcnicas de recopilacin y
anlisis de requerimientos.
Tcnicas de captura de
requerimientos.
Por lo general las personas que hacemos software nos encanta, es
un entretenido reto que se lleva en conjunto con un equipo de
trabajo, en el cual ponemos todo nuestro esfuerzo en construir un
software que utilice datos provenientes de nuestros clientes, los
procese para luego entregar informacin relevante para ellos, la
cual por lo general va agrupada y ordenada segn ciertos criterios,
sin embargo muchos software tienen defectos y cuando digo esto
no me refiero en particular a que cada cierto rato muestren un
mensaje de error o produzcan una cada en el rendimiento de
nuestro equipo, sino que, muchos software que nacen de una
necesidad del cliente pero que no cumplen con lo que el cliente ha
solicitado, veamos el siguiente ejemplo para ilustrar el concepto,
supongamos que hoy te regalar el auto de tus sueos y lo mejor
de todo es que el vehculo ser como tu lo especifiques, como
muchos que lean este libro sus requerimientos sern mas o menos
as:
Llantas aro 17.
Deportivo.
Motor muy poderoso.
De algn color que te guste.
Pgina 75 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
es
ambos,
el
problema
que
aqu
hubo
es
de
etapa
necesidades)
en
la
desde
que
obtenemos
nuestro
cliente,
los
en
requerimientos
la
que
(las
mediante
Pressman dice
Entrevista.
La entrevista es posiblemente la forma ms natural y rpida de
comunicacin con una persona, en informtica la entrevista debe ir
enfocada a aquellas personas que ms conocen sobre los procesos
de la organizacin y a las personas que utilizarn el sistema, estas
entrevistas pueden ser individuales o grupales y se recomienda
hacerlas cada cierto tiempo, ya que vers que los requerimientos
van a ir cambiando producto de la falta de entendimiento que los
clientes suelen tener sobre sus propios procesos.
Encuesta.
Las encuestas son documentos que tienen un conjunto de
preguntas relevantes del sistema que se desea construir, de esta
forma podemos obtener informacin ms precisa sobre los puntos
sobre los cuales necesitamos una respuesta cerrada, las preguntas
se hacen de forma verbal al encuestado, siendo el mismo
encargado de marcar la respuesta segn lo que el encuestado
haya dado como respuestas, las encuestas puede llevar preguntas
abiertas o de seleccin mltiple, en la que los encuestados debern
seleccionar una alternativa, esta tcnica es buena cuando lo que
Pgina 79 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Observacin directa.
Esta tcnica consiste en que el encargado de la toma de
requerimientos observa las personas mientras realizan su trabajo,
de esta forma se conoce cules son los procedimientos que se
realizan, quines son los encargados de hacerlos y cul es el orden
en el que se ejecuta.
Definicin de actividades.
Una
vez
los
requerimientos
han
sido
extrados
del
cliente
la
informacin
de
los
productos,
subir
sus
fotos,
mayor
cantidad
de
stock
de
productos,
estos
informes
se
Pgina 82 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
los
procesos
de
anlisis
de
requerimientos
siempre
se
agrupar
las
actividades
que
ests
analizando.
Este
los
grados
de
importancia
de
los
requisitos
Pgina 84 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
construir
estos
diagramas
existen
cuatro
elementos
principales:
Los rectngulos representan entidades externas, las cuales son
orgenes o destinos de los datos, es decir son todas aquellas cosas,
personas o sistemas que aportan o reciben datos como resultado
del proceso.
Pgina 85 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Las flechas representan los flujos de datos, los cuales viajan entre
las entidades y los procesos y entre los procesos y los almacenes
de datos.
NO
SI
NO
Proceso
SI
SI
SI
Almacn
NO
SI
NO
Pgina 87 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 88 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 89 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
coordinar la secuencia
de
los
procesos
los
es
analistas,
un
diagrama
quienes
diseado
disean,
para
controlan
ser
usado
por
los
y gestionan procesos.
actual.
Pgina 93 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Un
subproceso
dentro
de
es
un
conjunto
de
actividades
incluidas
cuyos
subprocesos
no
pueden
ser
Pgina 94 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
que
camino
seguir,
las
convergentes
Pgina 95 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
actividades
decisiones
que
se
de
asociacin,
permite
asociar
Pgina 96 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
fin
de
ilustrar
diferentes
capacidades
funcionales
con
o
responsabilidades.
Pgina 97 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 98 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Pgina 99 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Por
lo
tanto
siempre
recuerda
que
un
sistema
de
soluciones,
reconstruir
procesos
acciones
que
pasando
por
software
empresarial
pginas
web.
sus
tareas,
todo
ngulo
del
almacenamiento,
se
producen
muchos
procesos
de
traspaso
de
Actores.
Los actores se definen en un diagrama de casos de uso como entes
externos que interactan con funciones del sistema. De esta forma
un actor no necesariamente es una persona, puede ser una
entidad
una
idea.
Lo
que
sucede
es
que
cuando
las
casos
el
actor
no
es
una
persona,
sino
que
una
casa,
probablemente
desempees
alguno
de
los
Casos de uso.
Un caso de uso se define como una funcin que tiene o debe tener
el sistema y que es utilizada por un usuario. De esta forma los
casos
de
uso
se
transforman
en
las
acciones
que
debe
que
participan
del
proceso.
De
esta
forma
Relaciones.
Las relaciones permiten establecer la forma en que los actores y
los casos de uso se comunican y adicionalmente muestra la
relacin existente entre los casos de uso.
Existen cuatro tipos de relaciones en los diagramas de casos de
uso,
asociacin
de
comunicacin,
extensin,
inclusin
generalizacin.
La relacin de asociacin de comunicacin se establece entre el
actor y el caso de uso y nos permite definir en el contexto del
diagrama que el actor est utilizando que el caso de uso. Recuerda
que cada uno de los actores que aparezca en el diagrama debe
estar relacionado al menos con un caso de uso, pues la relacin
entre el actor y el caso de uso nos indica qu funcionalidad del
sistema ser utilizada por cada uno de los actores que estn
representados en ese escenario particular.
En la relacin de inclusin, la que graficamos con una lnea
segmentada que une dos casos de uso ms una flecha que indica
la direccin de la relacin, estamos representando dos casos de
uso que son complementarios. En la relacin de inclusin, un caso
de uso necesita de otro caso de uso para poder realizar una
operacin en particular. Recuerda que en la inclusin el resultado
del caso de uso incluido afecta el caso de uso que incluye por lo
tanto estn ntimamente relacionados los resultados de ambos.
Este
tipo
de
relaciones
se
grafica
utilizando
la
palabra
no
las
preguntas
anteriores
realizando
una
Comunicacin.
Es el tipo de relacin que se establece entre el usuario y el caso de
uso, se define con una lnea continua que une al actor y el caso de
uso.
Inclusin.
La relacin de inclusin nos permite mostrar la forma en que los
casos de uso se complementan con otros casos de uso a los cuales
incluyen para poder realizar una accin. Cuando el caso de uso
incluye a otro, el caso incluido sirve para complementar la accin
del primer caso de uso, vale decir, sin el caos de uso incluido, el
caso de uso inicial no puede completar su tarea.
Pgina 119 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Extensin.
En la relacin de extensin el caso de uso extendido, completa su
accin con el caso de uso extendido, es decir, el caso de uso
extendido, aumenta su funcionalidad con el caso de uso extendido,
pero el caso de uso extendido no es necesario siempre.
Generalizacin.
La relacin de generalizacin en los casos de uso permite definir
un caso de uso especializado para una situacin en particular, es
decir existe un caso de uso especfico que realiza una accin, pero
tambin un caso de uso que se especializa en realizar un proceso
en particular.
Flujo Normal.
La seccin del flujo normal pretende que definamos el flujo normal
de actividades que se pueden identificar en un caso de uso, este es
el camino feliz es decir el proceso en su estado ideal en donde
nada falla y todo est como queremos.
Adicionalmente al flujo normal se suele definir una serie de
caminos alternos que nos permitan saber cmo se comporta el
sistema que estamos analizando cuando el proceso no llega a buen
puerto. La realizacin de este tipo de anlisis es muy importante
pues muchas veces el flujo alterno puede definir una regla
importante respecto al flujo del proceso.
Pre-condiciones.
Las precondiciones permiten formalizar todas aquellas condiciones
de deben considerarse como requisitos para la ejecucin de
nuestro caso de uso
Post-condiciones.
Las post-condiciones con estados finales con los cuales termina el
caso de uso y que son obligatorios. Esto significa que el caso de
uso debe terminar su proceso con alguna de las condiciones
definidas en esta seccin.
Para clarificar el concepto, fjate en la definicin del caso de uso
que esta hecha en el siguiente texto:
Nombre del caso de uso: Registro de usuario
Actores: Usuario/Administrador
Objetivos: Registrar al usuario/administrador en el sistema
Pre-condiciones:
1. El usuario no debe estar registrado con anterioridad.
Flujo Normal:
1. El usuario solicita el registro.
2. El usuario llena el formulario de registro.
3. El sistema valida que los datos estn completos y que la informacin
sea del tipo correcto.
4. El sistema chequea que el usuario no se encuentre registrado con
anterioridad.
5. El sistema almacena los datos del usuario, asignndole los permisos
necesarios.
Pgina 123 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Ingeniera del Software: Un enfoque prctico, Roger S. Pressman, McGraw-Hill/Interamericana de Espaa, S.A.U. 2002,
ISBN 84-481-3214-9
8
El Lenguaje Unificado de Modelado. Manual de Referencia, Pearson Educacin, S.A. 2000, ISBN 84-7829-037-0
vimos
anteriormente,
en
el
mundo
real
los
objetos
Muy bien, ahora te debes estar preguntando Y que paso con los
grficos
del
diagrama?,
ahora
vamos
eso,
en
UML,
la
cuestin,
pero
el
resto
del
proceso
se
realiz
sin
tu
de
ocultar
comportamiento
acceso
las
te
imaginas
cuantos
ojos
quemados
existiran
si
te
-escudoProtector: Integer=20;
Los mtodos de la clase tambin tienen una nomenclatura
especfica, en este caso los mtodos se anotan de la siguiente
forma:
NombreMetodo(atributo:tipoDato)
En este caso tambin debemos explicar algunas cosas respecto al
formato,
el
nombre
del
mtodo
representa
el
nombre
del
el
analizar
el
problema
tratar
de
definir
qu
atributos
que
consideremos
que
no
estn
correctamente
agregar o quitar
que
almacena la cantidad de
goles
una
lnea
que
une
cada
una
de
las
clases,
que
permiten
diferenciar
los
tipos
de
relaciones
Asociacin.
La relacin de asociacin, se define cuando una clase se asocia con
otra para lograr un objetivo, este tipo de relacin es el ms bsico,
en este caso cada una de las clases tiene una instancia de la otra.
El conector puede incluir el nombre del rol en cada uno de los
Pgina 146 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Multiplicidad.
La cardinalidad o multiplicidad en una relacin establece el grado y
nivel de dependencia, de esta forma podemos determinar que
existen varios tipos de cardinalidad:
Asociacin calificativa.
Este tipo de asociacin est asociada a la relacin del tipo uno es a
muchos, en el cual se requiere explicitar algn atributo que
definir un identificador nico para una clase y de esta forma
poder diferenciar cada uno de los objetos de la relacin, por
ejemplo cada uno de los buses para un recorrido del Transantiago 9
9
http://es.wikipedia.org/wiki/Transantiago
est asociado al recorrido con una relacin del tipo uno a muchos,
para poder identificar a cada bus de forma individual ocupamos el
atributo patente del vehculo para establecer la relacin. De esta
forma la asociacin calificada quedara de la siguiente forma:
Asociacin reflexiva.
La asociacin reflexiva se da cuando la relacin se establece entre
elementos del mismo tipo, es decir la clase se relaciona consigo
misma, pudiendo establecer el rol para clarificar la relacin, por
ejemplo supongamos que necesitamos establecer la relacin
existente entre los trabajadores sabiendo que uno es el jefe y el
resto son empleados, si te fijas todos son empleados, pero su rol
los diferencia.
Herencia.
La asociacin de herencia permite que las clases que se relacionan,
lo puedan hacer en un nivel de especificidad, es decir que las
clases que se estn asociando son clases iguales salvo que una de
ellas es ms especfica, es decir implementa ms mtodos o los
mismos mtodos pero con una implementacin distinta.
Asociacin.
Existen algunos tipos especiales de asociacin que veremos a
continuacin,
estos
tipos
especiales
permiten
representar
asociaciones ms complejas.
La asociacin ternaria es una asociacin entre tres clases de forma
simultnea, la cual no puede ser leda o agrupada slo de a dos
clases pues pierde el sentido. Por ejemplo se puede establecer una
relacin entre artista, cancin e instrumento o entre jugador,
equipo y posicin. En los dos ejemplos anteriores podramos
analizar la relacin de a pares pero pierde su significado o
semntica, Para establecer la relacin ternaria se dibuja un rombo
entre las tres clases. Al igual que en el resto de las asociaciones,
puedes agregar caractersticas de cardinalidad a la relacin.
La
composicin
es
tambin
una
relacin
entre
Realizacin.
Una relacin de realizacin esta dada por una clase y una interfaz.
En orientacin a objetos, una clase de interfaz es una clase que
define el comportamiento de una clase pero jams la implementa,
esto que parece tan complejo lo podemos definir como una clase
que es un cascaron sin cdigo por dentro. Te estars preguntando
Y para que quiero tener una clase que no hace nada y que no
tiene cdigo?, la respuesta no es simple pero lo podemos explicar
mediante un ejemplo.
Supongamos que estas creando un video juego y debes crear las
clases de tu juego, si te fijas los objetos de la pantalla se estn
moviendo, pero la nave se mueve en funcin de las teclas que
presiones en el teclado o de los botones del joystick que presiones,
mientras que las balas se desplazan siguiendo una trayectoria que
no se puede cambiar, ambos objetos se desplazan pero lo hacen
de forma distinta, por lo tanto como ambos poseen el mismo
mtodo (mover) pero los dos lo hacen de forma distinta entonces
se crea una clase de interfaz que posea el mtodo y como este
mtodo o comportamiento no se programa, le da la libertad a las
clases que heredan de esta clase de interfaz a que lo implementen
de forma independiente.