ANLISIS Y DISEO ORIENTADO A OBJETOS

Unidad 1 - ANLISIS ORIENTADO A OBJETOS

ANLISIS Y DISEO ORIENTADO A OBJETOS

Indice
Introduccin3
TEMA 1. Fases del anlisis orientado a objetos

TEMA 2. Conceptos de orientacin a objetos

2.1 Clase
2.2 Atributo 
2.3 Mtodo
2.4 Encapsulamiento
2.5 Polimorfismo
2.6 Herencia
2.7 Relaciones

2.7.1 Uno a uno 1..1

2.7.2Uno a muchos 1*
2.7.3 Un nmero especfico de ocurrencias n..m
2.7.4 Cero a muchos 0..*
2.7.5 Muchos a muchos: *..*, o *

6
7
8
9
10
10
10

11
11
12
13
13

TEMA 3. Requerimientos15
3.1 Clasificacin de requerimientos
3.2 Tcnicas de captacin de requerimientos

17
18

TEMA 4. Anlisis gramatical de problemas

21

IDEAS FUERZA

23

BIBLIOGRAFA24

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

Introduccin
La tecnologa avanza vertiginosamente lo que conlleva a que los sistemas se deban adecuar de la
manera ms natural posible a dichos avances. Todos los sistemas estn afectos a cambios de esta
ndole, cambios que se deben enfrentar desde una perspectiva analtica, sin afectar al normal
funcionamiento de stos.
La orientacin a objetos es una metodologa que permite realizar anlisis, desarrollo e implementacin de cualquier sistema, y su uso correcto permite que ste sea consistente entre lo que ha
sido definido en una primera etapa y lo que se obtiene una vez que ha sido construido.
Los objetos son una parte fundamental en todo sistema integrado, los cuales se tornan cada vez
ms complejos debido a las condiciones externas e internas que los afectan. Adems, se debe
tener presente que las normas, fases y estructuras disponibles para realizar el correcto anlisis de
un sistema y poder lograr bosquejar una correcta solucin, sern diferentes dada la naturaleza del
problema. A esto se suma que todo ente que interacta con otro tendr, de una u otra manera,
incidencia en el resultado final del estudio, por tanto, se torna relevante el definir de ante mano,
valores, actores, lmites o fronteras, acciones, dependencias, condiciones, restricciones y mbito
en el cul se desarrollar la solucin y la incidencia de sta con el entorno.

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

TEMA 1. Fases del anlisis orientado a objetos

La orientacin a objetos es un paradigma que permite ver al software como un conjunto integrado
de componentes llamados objetos, los cuales disponen de estructuras que permiten describir su
naturaleza (lo que son) y las acciones a las que pueden responder (lo que hacen). Este paradigma,
dentro del mbito del desarrollo de sistemas, se contrapone al modelo tradicional de desarrollo de
software, donde la programacin es ms bien lineal y las estructuras de datos en s, estn absolutamente separadas del comportamiento al que pueden verse afectas.
En este contexto, el anlisis orientado a objetos consiste en un mtodo que examina lo que se
necesita que el sistema realice (los requerimientos) desde el punto de vista de las clases y objetos
encontrados en el dominio (problema), y en las relaciones de asociacin e interaccin que existen
entre ellos. El objetivo de AOO es que los requerimientos sean correcta y completamente representados mediante el paradigma de la orientacin a objetos.
Existen pilares fundamentales que sustentan el AOO, y stos son: objeto, abstraccin, identidad,
clase, herencia, encapsulacin y polimorfismo.
El proceso de anlisis orientado a objetos consiste en analizar un problema y darle solucin desde
la perspectiva del mundo real. El elemento fundamental para dar solucin a cualquier tipo de problema es el objeto, cuyas caractersticas y comportamientos forman parte de l en forma indivisible.
Este proceso de anlisis consiste en las siguientes fases:

Justificar los
casos de uso

Captura de
requerimientos

Formulacin de diagramas de clase

Documentar
diagramas de clases

Elaborar diagramas de
actividad

Elaborar diagramas de
estado

Imagen 1: Fases de anlisis orientado a objetos. Fuente: elaboracin propia.

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

Captura de requerimientos, donde se solicita la informacin necesaria para poder saber exactamente que se necesita que haga el programa, identificar problemas y soluciones deseadas,
entre otros.

Formular el diagrama de clases, en esta etapa se deben identificar las clases, las relaciones
entre ellas y los atributos de cada una, adems de describir las operaciones que ofrecern
cada una de ellas.

Elaborar diagramas de estado, en esta etapa es necesario realizar una descripcin a travs
de los diagramas de estados el modelo interno de las clases que se identificaron en la etapa
anterior.

Elaborar diagramas de actividad, luego que ya tenemos definidas las clases y los diagramas
de esto debemos describir mediante diagramas de actividad los algoritmos que describen las
operaciones de la clase.

Documentar exhaustivamente el diagrama de clases

Justificar los casos de uso, para finalizar, ser necesario justificar los casos de uso del problema desde los diagramas de objetos, detallndolos para los objetos recin identificados.

Es importante tener presente que toda problemtica tendr un universo de aristas por las cuales
ser posible pre-visualizar una salida lgica para dar solucin a lo planteado, pero es relevante
recopilar la mayor cantidad de informacin con el propsito de estructurarla, usando alguna metodologa de resolucin de problemas.
El correcto proceso de anlisis de la problemtica permitir la toma correcta de decisiones y sin
duda un mejor control sobre las operaciones, una gestin eficiente de proyectos y un uso adecuado de las tecnologas existentes. Por el contrario, el uso no adecuado de la informacin de entrada,
la incorrecta manipulacin de los datos o el insuficiente control de cada entrada y salida, generarn
costos adicionales los que, en definitiva, se traducirn en prdida de tiempo y gastos de recursos
adicionales no contemplados en una primera etapa.

La idea fundamental del anlisis preliminar es bosquejar, de la manera ms cercana posible a la

realidad, tanto el tiempo como los posibles recursos a utilizar durante el desarrollo del estudio o
anlisis del caso de estudio.

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

TEMA 2. Conceptos de orientacin a objetos

La orientacin a objetos consiste en ver al mundo real como un conjunto de objetos que interactan entre s. A su vez, un objeto se puede entender como la representacin de cualquier elemento del mundo real que posee caractersticas, propiedades y comportamientos que le permiten
relacionarse con otros objetos.
En forma concreta, el anlisis y diseo orientado a objeto nos entrega una serie de resultados
que describen la solucin de software a implementar en una empresa, negocio u organizacin. En
general, estos resultados se reflejan en diagramas y definiciones que ayudan al desarrollador y al
usuario a entender y lograr acuerdos sobre el producto final.
El anlisis y diseo orientado a objetos es un paradigma que permite ver al software como un conjunto integrado de componentes llamados objetos, los cuales disponen de estructuras que permiten describir su naturaleza (lo que son) y las acciones a las que pueden responder (lo que hacen).
Este paradigma, dentro del mbito del desarrollo de sistemas, se contrapone al modelo tradicional
de desarrollo de software, donde la programacin es ms bien lineal y las estructuras de datos en
s, estn absolutamente separadas del comportamiento al que pueden verse afectas.
Existen pilares fundamentales que sustentan el diseo orientado a objeto y stos son: clase, atributo, mtodo, encapsulacin, polimorfismo y herencia.

2.1 Clase
Las clases son un conjunto de objetos que poseen caractersticas y comportamientos idnticos, esto quiere decir, que los objetos son definibles con los mismos atributos, operaciones (mtodos) y relaciones.
La representacin grfica de una clase est compuesta por un rectngulo con tres divisiones en
su interior. Toda clase debe tener un nombre que le permita distinguirse de las dems clases del
modelo. Dicho nombre, por lo general, es un sustantivo empleado en forma singular, expresado en
forma simple. Observa la siguiente figura en la que grficamente se denota una clase, el nombre
que la define sera pelota:

Pelota

Figura 1: Ejemplo de una clase.

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

2.2 Atributo
Son generalmente utilizados para definir los valores de los datos sin identidad, tales como nmeros y cadenas de caracteres. En este sentido, un atributo define las caractersticas que posee una clase. Observa
el ejemplo en el que se detallan los atributos de la clase llamada pelota, que de acuerdo a lo expuesto,
posee los atributos: tamao-actual, color-actual y estado-actual.

Pelota
+tamao-actual
+color-actual
+estado actual

Figura 2: pelota de basquetbol y el equivalente de sta graficado en una clase con sus atributos.

Dado que no es necesario exponer todas las caractersticas de la clase al momento de generar el diagrama, es posible mostrar solo los atributos y mtodos bsicos que la definen. El nivel de detalle de la
clase depender, por una parte, del software con el que se generen los diagramas y por otra, del nivel de
abstraccin al cual se est haciendo referencia, que por lo general corresponde a la vista analtica o de
implementacin.
Los atributos describen las caractersticas propias de los objetos que son parte de una clase. La notacin
para definir los atributos de una clase est dada por la siguiente sintaxis:

Ejemplo prctico: Sistema de remuneraciones

Ejemplo prctico: + Rut: String = 1-9
El ejemplo nos muestra un tipo especfico de visibilidad, pero existen
tres tipos diferentes, estos son:
+: pblica, esto quiere decir que el atributo es visible a todos los
clientes de la clase.
- : privada, el atributo es solo visible en la clase.
#: protegida, el atributo puede ser visto en las subclases de la clase en el que se define.
Ahora continuemos revisando los distintos elementos que componen el
ejemplo:
El tipo define el atributo, que puede corresponder a los tipos definidos
genricamente. Los tipos ms usados son: string, char, boolean, integer,
real, double, float. Pueden existir otros tipos, pero eso depender de la
complejidad del diagrama y de las clases que lo componen. En el ejemplo, el atributo Rut es de tipo String.

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

El valor predeterminado corresponde a una expresin con el valor

inicial, que contendr el atributo cuando sea creado un nuevo objeto.
En el ejemplo, el atributo Rut tiene un valor predeterminado igual a
1-9.
La lista de propiedades contiene todos los valores permitidos en un
atributo. Normalmente se utiliza para tipos de datos enumerados con
valores conocidos, tales como color o estado, entre otros. En el ejemplo, el atributo Rut tiene una lista de propiedades vaca o, simplemente, la lista no existe, por lo tanto es opcional.
En la imagen siguiente se representa grficamente la clase vista, solo desde la perspectiva de sus
atributos:

Pelota
+tamao-actual: string = pequea {pequea,mediana,grande}
+color-actual: string = rojo {verde,rojo,blanco,azul}
+estado actual: boolean = false
Figura 3: clase pelota y sus atributos. Fuente: Elaboracin propia.

2.3 Mtodo
Los mtodos describen el comportamiento o las acciones a las que pueden responder los objetos
de una clase. Por ejemplo: Una persona puede comer, dormir, estudiar, trabajar, comprar, etc. Cada
una de estas acciones constituyen los mtodos de la clase Persona. La notacin para definir los
mtodos est dada por la sintaxis:

visibilidad nombre-mtodo (lista de parmetros):

tipo devuelto {lista-propiedades}
Para los mtodos la visibilidad tambin puede ser + (pblica), - (privada) o # (protegida). Pero en
este caso el nombre representa una cadena de texto que define el mtodo. La lista de parmetros
corresponde al conjunto de parmetros formales, separados por coma, donde se debe especificar
cada uno de los atributos de la clase de la siguiente manera:

nombre: tipo = valor predeterminado

Mientras que el tipo devuelto corresponde al valor de retorno que genera el mtodo si es que existe,
por lo tanto, no es obligatorio devolver un valor, dependiendo de la naturaleza del mtodo en s.
La lista propiedades corresponde al conjunto de valores permitidos dentro del mtodo. Inicialmente, la clase expuesta quedara definida de la siguiente forma, referida al conjunto de mtodos
que la conforman:

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

+ rebotar()
+ rodar()
+ inflar()

En la siguiente figura se aprecia la clase con los mtodos incluidos en ella:

Pelota
+tamao-actual
+color-actual
+estado actual

Figura 4: clase pelota con atributos y mtodos. Fuente: Elaboracin propia.

Tambin es posible generar un mayor nivel de detalle en los mtodos que componen la clase. De
acuerdo a lo anterior, solo se sabe que la pelota rebota, rueda y se infla. Pero es posible agregar a
cada uno de esos mtodos informacin adicional para, eventualmente, indicar que dicho mtodo
tendr un comportamiento distinto de acuerdo a ciertas condiciones de entrada.
En la siguiente imagen se exponen mtodos con mayor grado de detalle, segn el formato previamente definido:

Pelota
+tamao-actual: string = pequea {pequea,mediana,grande}
+color-actual: string = rojo {verde,rojo,blanco,azul}
+estado actual: boolean = false
+rebotar (altura: integer = 10): integer

Figura 5: clase pelota con atributos y mtodos detallados.

Fuente: Elaboracin propia.

2.4 Encapsulamiento
Es un mtodo de diseo que consiste en ocultar la composicin de los objetos de manera tal que
slo se aprecien los resultados asociados a la funcionalidad de ellos.

Unidad 1: Introductorio

ANLISIS Y DISEO ORIENTADO A OBJETOS

2.5 Polimorfismo
Es la capacidad que tienen los objetos de una clase de responder al mismo mensaje o evento en
funcin de los parmetros utilizados durante su invocacin. Un objeto polimrfico es una entidad
que puede contener valores de diferentes tipos durante la ejecucin del programa.

2.6 Herencia
Consiste en crear objetos tipo, que poseen caractersticas y acciones definidas usables por cualquier
objeto que las necesite, permitiendo, adems, ampliar ese rango de caractersticas y funcionalidades.

2.7 Relaciones
En un diagrama de clases permiten que estas interacten entre s, dado que, por lo general, las
clases son objetos que en su conjunto componen elementos estticos que dan cuenta de la problemtica. No se consideran como elementos aislados dentro del diagrama, por lo que es necesaria
una o ms relaciones que les permitan interactuar.
La relacin bsica que existe en un modelo o diagrama de clases es la asociacin. Por definicin,
este tipo de relacin corresponde a una relacin semntica entre los objetos de dichas clases. La
asociacin es una relacin estructural que indica que los objetos de una clase estn conectados
con los objetos de otra. Cuando la asociacin entre los objetos es de tipo semntica, se dice que la
asociacin es binaria. Esto quiere decir que existe un nmero determinado de ocurrencias que
pueden suceder de acuerdo a la naturaleza de la relacin.

Propietari o

Vehiculo

+posee
1..*

+pertenece a 0..*

Figura 6:relacin ente propietario y vehculo. Fuente: elaboracin propia.

Cliente

Cuenta

+posee
0..*

Figura 7:relacin ente cliente y cuenta. Fuente: elaboracin propia.

En las imgenes se ilustran dos tipos de navegacin entre clases: la primera asocia al propietario con
el vehculo. La lectura que puede darse al tipo de relacin es: la persona posee cero, uno o muchos
vehculos y el vehculo pertenece a un propietario. El segundo caso da cuenta que un cliente posee
cero, una o muchas cuentas, pero no se especifica cuntos clientes son dueos de esa cuenta.

Unidad 1: Introductorio

10

ANLISIS Y DISEO ORIENTADO A OBJETOS

Para profundizar

Revisa el libro UML: modelado de software para profesionales,

captulo 4 de Fontela (2011).

A modo de resumen, se puede decir que toda relacin posee:

Nombre: una relacin puede tener un nombre que es usado para describir la naturaleza de ella.

Esto permite eliminar cualquier ambigedad en el significado que se le quiera dar. Es importante
mencionar que el nombre de la relacin debe ser nico en todo el diagrama de clases.
Rol: cuando las clases que participan de la relacin juegan un rol especfico, este debe ser indicado
como corresponde. Normalmente, se usa un nombre descriptivo al final de la lnea, en cada lado de
la relacin.
Multiplicidad o cardinalidad: indica la cantidad de objetos que se encuentran conectados en
una instancia de asociacin. Dicho de otra forma, las veces que una puede ocurrir en relacin con la
otra.

Tomando en consideracin la definicin de multiplicidad o cardinalidad, podemos ver que esta posee
diferentes rangos. Estos pueden ser:

2.7.1 Uno a uno 1..1

Un pas posee una capital y esa capital pertenece solo a un pas.

Pais

+tiene

+pertenece a

Capital

Figura 8: ejemplo de cardinalidad uno a uno. Fuente: elaboracin propia.

2.7.2Uno a muchos 1*
Una persona posee una o muchas credenciales y esas credenciales corresponden a solo una persona.

Persona

+tiene
1

+pertenece a

Credencial

Figura 9: ejemplo de cardinalidad uno a muchos. Fuente: elaboracin propia.

Dentro de la relacin uno a muchos (1..*) es posible encontrar un tipo de relacin especial, en la cual
uno o ms atributos identifican en forma unvoca a la clase, que es la base para que se genere la relacin.
Este tipo de relacin se conoce como asociacin calificativa. Observa el siguiente ejemplo:

Unidad 1: Introductorio

11

ANLISIS Y DISEO ORIENTADO A OBJETOS

Bus

+patente

Recorrido

+tiene
1..*

Figura 10: ejemplo de cardinalidad uno a muchos, asociacin calificativa. Fuente: elaboracin propia.

Para identificar a cada bus en particular se utiliza el atributo patente, que a su vez es la base para la relacin del recorrido asociado a este. Tambin es posible que objetos del mismo tipo se relacionen entre s,
dando origen al tipo de relacin conocida como asociacin reflexiva, donde el nombre de la relacin clarifica el rol que cumple el objeto al relacionarse consigo mismo, como se aprecia en el siguiente ejemplo:

es jefe de

Empleado
1..*

Figura 11: ejemplo de cardinalidad uno a muchos, asociacin reflexiva. Fuente: elaboracin propia.

El objeto empleado se relaciona consigo mismo. El nombre de la relacin da la connotacin necesaria

para indicar que una de las ocurrencias de esta clase tendr carcter mandatorio para el resto de las ocurrencias de la misma clase. La asociacin reflexiva es jefe de determina que, si bien todas las instancias
son del tipo empleado, el rol desempeado por una de las instancias es distinto al resto y esta diferencia puede verse reflejada en una accin o mtodo en particular, por ejemplo: dar orden().

2.7.3 Un nmero especfico de ocurrencias n..m

Como se mencion anteriormente, en toda relacin debe existir una cardinalidad que defina el nmero
de ocurrencias que pueden originarse entre las clases asociadas. Si bien no es obligacin restringir el
nmero de ocurrencias, es posible limitarlas indicando en la relacin el nmero mnimo y mximo que es
posible que sucedan.
Si se tratase literalmente la relacin entre las clases doctor y paciente, se podra decir en forma genrica
que un doctor atiende a uno o ms pacientes, pero de acuerdo a las necesidades reales, podra acotarse
el nmero de atenciones. Observa el siguiente ejemplo:

Doctor

Paciente

atiende
1

1..10

Figura 12: ejemplo de cardinalidad un nmero especfico de ocurrencias. Fuente: elaboracin propia.

Unidad 1: Introductorio

12

ANLISIS Y DISEO ORIENTADO A OBJETOS

2.7.4 Cero a muchos 0..*

Una asociacin opcional indica que es posible que sucedan o no ocurrencias entre las clases relacionadas.
Para tales efectos, el smbolo 0 denota que puede o no ocurrir dada esa relacin. Observa el siguiente
ejemplo que da cuenta de ello.

Cliente

+posee

+corresponde a

Cuenta

1..*

+tiene

+es de

Tarjeta
de credito

0..*
Figura 13: ejemplo de cardinalidad cero a muchos. Fuente: elaboracin propia.

Un cliente que posee una o muchas cuentas, no est obligado a tener tarjetas de crdito, por lo tanto,
efectivamente, puede o no tener tarjetas de crdito.

2.7.5 Muchos a muchos: *..*, o *

Una asociacin muchos a muchos, tambin descrita como asociacin n..n, indica que las ocurrencias
pueden ser mltiples en ambos sentidos. Segn el siguiente ejemplo, es posible deducir que un profesor
dicta una o muchas asignaturas y las asignaturas pueden ser dictadas por muchos profesores.

Profesor

Asignatura

dicta
*

Figura 14: ejemplo de cardinalidad muchos a muchos. Fuente: elaboracin propia.

Una asociacin muchos a muchos, tambin descrita como asociacin n..n, indica que las ocurrencias
pueden ser mltiples en ambos sentidos. Segn el siguiente ejemplo, es posible deducir que un profesor
dicta una o muchas asignaturas y las asignaturas pueden ser dictadas por muchos profesores.

Profesor

Asignatura

dicta
*

Catedra
Figura 15: ejemplo de clase de asociacin. Fuente: elaboracin propia.

Unidad 1: Introductorio

13

ANLISIS Y DISEO ORIENTADO A OBJETOS

En este caso, Ctedra es una clase de asociacin entre Profesor y Asignatura. Una forma ms elaborada de componer las asociaciones es tratarlas como agregacin. Existen tres tipos de agregaciones:
Agregacin normal.
Agregacin compartida.
Agregacin de descomposicin.
En cada uno de estos tipos de agregacin es posible indicar el grado de acoplamiento entre las clases, es
decir, cuanto afecta el comportamiento de una clase sobre otra. Tambin es posible unir clases en forma
semntica y dependientes unas de otras, esto quiere decir que una clase podra trabajar en conjunto con
otra clase para lograr un objetivo comn. Al respecto, se distinguen dos tipos:
Relacin de dependencia.
Relacin de generalizacin.
En estos tipos de relacin, la composicin de las clases est vinculada entre s, por lo tanto, la relacin
entre ellas es ms fuerte debido a la informacin que maneja una respecto a la otra.

Para profundizar

Video: Clase asociacin http://vimeo.com/79298216

Video: Generalizacin http://vimeo.com/79298214
Video: Composicin http://vimeo.com/79298215
Video: Asociacin binaria http://vimeo.com/79298213

Unidad 1: Introductorio

14

ANLISIS Y DISEO ORIENTADO A OBJETOS

TEMA 3. Requerimientos
Todo sistema de informacin existe para dar solucin a problemas y/o necesidades comunicacionales. Es lgico decir que cada vez que se presenta una necesidad de informacin, aparecer un sistema que intente mejorar esta situacin. Estos se construirn pensando en que su comportamiento
futuro con el medio, los flujos de informacin en los que participe y sus actividades de control,
harn desaparecer el problema detectado. Al comenzar la exploracin de los requerimientos,
generalmente ocurren dos hechos bsicos:

Los clientes y usuarios se renen con el equipo informtico, dando su visin acerca de la
situacin actual, sus consecuencias y que solucin esperan obtener.

En esta primera fase, l labor del equipo informtico ser la de preguntar, analizar, internalizar y presentar una solucin que resuelva de la forma ms adecuada el problema.

Por lo tanto, de manera ms esquemtica, podemos decir que nuestra labor ser investigar la situacin actual de la organizacin, al punto de conocer a fondo los procesos que se estn llevando a cabo.
Esto lo hacemos para tomar conocimiento del entorno en el cual trabajaremos, de la misma forma en
que un mdico, para poder realizar un diagnstico, enfoca su atencin en las dolencias que tenemos
y es por esto que necesitamos identificar y comprender los requerimientos del cliente.

Necesidad de informacin.
Idea de un nuevo sistema

Anlisis del
problema

Conjunto de Requisitos

Descripcin del
producto

Diseo

Definicin del problema

Figura 16: ejemplo de clase de asociacin. Fuente: elaboracin propia.

Tal como lo vemos en la imagen anterior el analizar el problema nos ayuda a conocer el contexto sobre el cual trabajaremos, comprender cmo trabajan actualmente los procesos dentro de
la organizacin bajo estudio y las decisiones que toman, visualizar la interaccin con sistemas y
entidades externas, como tambin comprender las causas del problema y sus consecuencias en
la actualidad. Recuerda que debemos conocer la organizacin para diagnosticar. Mientras que
la descripcin del producto se realiza una vez que hemos comprendido el problema y su entorno.
Unidad 1: Introductorio

15

ANLISIS Y DISEO ORIENTADO A OBJETOS

En este punto usaremos ese conocimiento (definicin del problema) para describir la meta que
deseamos lograr con el desarrollo del nuevo sistema. La descripcin del producto la realizaremos
de manera operativa, es decir, detallaremos lo que ser capaz de hacer el sistema para resolver
el problema o necesidad. Posteriormente, la fase de diseo da forma a los requerimientos establecidos previamente. Aqu se nos permite modelar la arquitectura del hardware y software, los componentes, mdulos y datos de un sistema de informacin, para satisfacer ciertos requerimientos.
Los requerimientos involucran tareas o actividades relacionadas a la determinacin de las necesidades, condiciones o requisitos que debe satisfacer un software, sea este un nuevo producto o la
modificacin de alguno existente. Un requerimiento emana de una necesidad directa solicitada por
alguien, necesidad que debe ser resuelta de acuerdo a peticiones especficas.
En el mbito del desarrollo de software, los requerimientos son fundamentales para evaluar alternativas de solucin, puesto que son, en definitiva, los que permiten realizar un primer acercamiento a posibles soluciones dentro del marco establecido para ello. Estos representan:

El conjunto de resultados obtenidos luego de utilizar el sistema.

El conjunto de las acciones posibles de realizar, as como las no permitidas o restringidas
de realizar por el sistema.

Cabe sealar que una buena especificacin de requerimientos no es factible de lograr 100% en un
primer encuentro o acercamiento con el usuario, principalmente porque en algunos casos se dan
situaciones tales como:

No son obvios y provienen de variadas fuentes.

No siempre es fcil expresarlos de forma verbal.
Existen los de distinto tipo y diferentes grados de complejidad.
Pueden variar en el tiempo.
Hay muchas entidades interesadas en que ellos se cumplan.

Cmo reconozco un requerimiento?

Piensa lo siguiente: tu cliente te cuenta que le gustara que el sistema le mostrara el resumen de venta diaria al final del da pues en
estos momentos debe realizar este procedimiento de manera manual sumando las boletas. Ac podemos observar claramente que
existe un problema de informacin, pues sta no se encuentra disponible en el momento que la necesitamos. Consecuentemente
podemos reparar esta situacin planteando el requerimiento de: el sistema generar el reporte de las ventas diaria al final del da.
Entonces, todo requerimiento se obtiene a partir de la necesidad planteada por un cliente o entidad. Por lo cual son identificados a
travs del acercamiento con los clientes, entrevistas, observacin directa y entender el contexto o cmo funciona el negocio, ya que
muchas veces, los proyectos no fracasan porque el cliente no tiene claro lo que quiere, sino porque es imposible implantarlo en el
entorno en el que se encuentra, debido a condiciones totalmente ajenas a las caractersticas del problema en cuestin.

Unidad 1: Introductorio

16

ANLISIS Y DISEO ORIENTADO A OBJETOS

En definitiva, los requerimientos definen el problema y el diseo define la solucin, por lo tanto, un buen anlisis de requerimientos no da por sabidas situaciones que podran ser obvias, no
existen alternativas por defecto, ni se describen situaciones especficas, a no ser que el cliente lo
requiera en cuanto a software o hardware.

3.1 Clasificacin de requerimientos

Antes de poder hacer un levantamiento de requerimientos es necesario entenderlos y comprender la
diferencia entre los distintos tipos de requerimientos. Estos se clasifican en tres tipos:

a)Requerimientos funcionales: Permiten describir la funcionalidad del o los servicios que el nuevo
software proveer. En este aspecto dependen del tipo de software a desarrollar y los posibles usuarios de
l. Cuando estos requerimientos representan requisitos de usuario son especificados en forma general,
pero cuando se tratan como requisitos del sistema, son detallados indicando claramente la funcionalidad,
las entradas y salidas correspondientes a los procesos asociados. Por ejemplo:

El sistema debe tener acceso web.

El sistema debe validar a los usuarios.
El sistema debe emitir reportes diarios.

b)Requerimientos no funcionales: Corresponden a los requisitos que forman parte de factores

externos al sistema, pero que pueden alterar el normal funcionamiento del mismo. Normalmente los requerimientos no funcionales se tratan de cuantificar, de tal manera que sean medibles en forma objetiva,
pero no siempre es factible, por lo que muchas veces no es posible verificarlos. Por ejemplo:

Requisitos legales,
Requerimientos de equipamiento tcnico,
Requerimientos de personal calificado, etc.

Y ms especficamente:

Un equipo de enfriamiento por lquido.

Computador de ltima generacin.
Equipo de sobreproteccin de voltaje.

c)Requerimientos de dominio: Estn referidos a aquella parte del diseo que es particular (entorno
directo) al problema que se desea resolver. En este aspecto, no es posible ofrecer una metodologa para
realizar el anlisis, puesto que, en cada caso, el requerimiento es diferente. Por ejemplo, los requerimientos de dominio (particulares) de una aplicacin web, pueden ser muy distintos a los requerimientos de
dominio de un sistema de escritorio.

Unidad 1: Introductorio

17

ANLISIS Y DISEO ORIENTADO A OBJETOS

Requerimientos
Permite a los desarrolladores explicar cmo han entendido lo
que el cliente espera que el sistema realice.

Permite al equipo de pruebas demostrar al cliente, por medio

de hechos, que lo solicitado se cumple a cabalidad.
FUNCIONES QUE CUMPLEN LOS REQUERIMIENTOS.

3.2 Tcnicas de captacin de requerimientos

El proceso de captura de requerimientos es una etapa vital en el marco del desarrollo de software. A partir de este proceso, se descubren y analizan las necesidades o requisitos del usuario del sistema que se
construir. Generalmente, el usuario no transmite los requerimientos tal cual son necesarios de resolver,
es por esto que el equipo de desarrollo puede encontrarse con algunos inconvenientes al momento de
realizar el levantamiento de la informacin y los procesos que esta etapa involucra.
En la actualidad existen variadas metodologas que permiten normalizar el desarrollo de este proceso, las
cuales indican la secuencia de pasos a seguir, las interacciones, relaciones y personas involucradas en el
proceso, sin embargo, es complejo poder definirlos de manera clara cuando los procesos implicados no
han sido bien entendidos por el equipo de desarrollo, lo que finalmente generar un producto deficiente.
Por tal motivo, se hace necesaria la utilizacin adecuada de metodologas en beneficio de la solucin.
La realizacin correcta del anlisis de requerimientos se sustenta fundamentalmente en trabajar sin
supuestos ni predefiniciones, ya que es necesario comprender el contexto en el que se sita la problemtica y acotar claramente lo que se necesita. Existen variadas tcnicas para realizar la captura de requerimientos, dentro de las cuales se pueden apreciar las siguientes:

a)Entrevista: es un acto de comunicacin verbal que puede establecerse entre dos o ms personas,
con el propsito de obtener informacin. Es ideal que el entrevistado conozca el negocio o bien los procesos que intervienen en la problemtica en estudio, de tal manera que toda informacin obtenida sea
lo ms certera posible y represente la real necesidad del momento. El tipo de preguntas a realizar puede
ser:

Abiertas: preguntas que dan la posibilidad de respuestas amplias. Por ejemplo: cmo evaluara
el actual sistema en cuanto a los procesos que involucra? el sistema es relativamente estable en
condiciones ambientales normales?

Cerradas: preguntas de las que se espera una respuesta concreta. Por ejemplo: el sistema debe
estar operativo las 24 horas? Cuntas personas utilizan el sistema?

Unidad 1: Introductorio

18

ANLISIS Y DISEO ORIENTADO A OBJETOS

Hipotticas: son aquellas preguntas que plantean, como su nombre lo indica, situaciones hipotticas. Por ejemplo: qu sucedera si el servidor de base de datos deja de funcionar en algn momento?

De sondeo: son preguntas que permiten obtener informacin extra para interiorizarse en el tema.
Por ejemplo: existe algn encargado de revisar el equipamiento computacional en forma permanente? ha previsto tener un sistema de respaldo de informacin?

Es importante mencionar que el tipo y la cantidad de preguntas a realizar estarn ligadas directamente al mbito asociado del problema, por tanto puede ser necesario realizar ms de un tipo de
ellas para obtener informacin relevante para el o los desarrolladores.

b)Encuesta: corresponde a un tipo de estudio en el cual el investigador utiliza un cuestionario prediseado, sin modificar, alterar o controlar el proceso que se investiga. La informacin es obtenida a partir
de un conjunto de preguntas normalizadas y dirigidas a una muestra representativa de las personas que
componen el entorno en el cual se presenta la problemtica. La forma temtica de preguntas normalmente involucra alternativas en las respuestas, en donde el encuestado debe seleccionar la que mejor
representa la realidad que vive en torno al problema. Es importante mencionar que la persona o el grupo
que aplica la encuesta debe seleccionar el conjunto de preguntas ms representativo de acuerdo a la
naturaleza de lo que se analiza.

c)Observacin directa: mediante esta tcnica es posible recopilar informacin observando el entorno, las personas y las actividades que cada uno de ellos realiza. De esta forma, quien realiza el estudio,
puede obtener datos acerca de procedimientos y funciones, adems de saber quines son los encargados de realizarlos.
Los tres mtodos antes mencionados nos ayudarn a levantar requerimientos, pero para poder tener una
visin completa del problema necesitamos conocer tambin el contexto sobre el cual trabajaremos, comprender cmo se trabajan actualmente los procesos dentro de la organizacin bajo estudio y las decisiones que toman. De esta forma se puede visualizar y comprender la interaccin con sistemas y entidades
externas, entender por qu surge el problema (causas) y cmo afecta en la actualidad (consecuencias).
Algunas preguntas que te pueden ayudar en tu investigacin podran ser:

A qu se dedica la empresa?
Cules son los datos que el sistema requiere para poner en marcha sus procesos?
Cules son las restricciones de tiempo existentes?
Cules son las cargas de trabajo mnimas y mximas?
Cules son las medidas de desempeo que presenta la organizacin?

Para investigar procesos te sugerimos hacer las siguientes preguntas:

Cul es el objetivo del proceso? Cul es su rol en la empresa?
Cules son las actividades que se llevan a cabo dentro del proceso?
Cul es el espacio fsico donde se lleva a cabo el proceso?
Unidad 1: Introductorio

19

ANLISIS Y DISEO ORIENTADO A OBJETOS

Quines son los encargados de realizar y supervisar el proceso?

Cunto es el tiempo que tarda en realizarse?
Quines son los que utilizan el resultado del procesamiento (informacin)?

Todas las preguntas anteriores, adems de comprender la situacin actual se busca descubrir y
comprender las necesidades del usuario, ya que debemos ser conscientes de que el sistema que
desarrollaremos ser la herramienta de trabajo que diariamente usarn para trabajar.

Cuando los requerimientos son redactados en trminos formales y de manera detallada, en la

prctica estaremos construyendo el documento llamado Especificacin de Requerimientos.

Unidad 1: Introductorio

20

ANLISIS Y DISEO ORIENTADO A OBJETOS

TEMA 4. Anlisis gramatical de problemas

Durante la captura de requerimientos es posible determinar las variadas necesidades de la organizacin o entidad en estudio. Es relevante que el espectro de solucin est acotado y sea realista,
conforme a la informacin levantada en el anlisis previo.
Mientras mayor sea la cantidad de procesos involucrados, es probable que ms complejo sea en s
la estructura organizacional y las personas que participan en esos procesos. Pero sin duda, existen
procesos primarios que son los que mueven a la empresa u organizacin y en los que hay que colocar mayor atencin a la hora de capturar requerimientos.

Ejemplo prctico: Empresa retail

Una empresa de retail compra y vende productos a clientes finales, esa
es su razn de existir, pero no se debe descuidar de los procesos secundarios que en su conjunto son tan importantes como el proceso de
venta en s.
Es probable que el servicio de venta tenga asociado un servicio de
control de calidad previo, que regula los procesos de certificacin de
normativas vigentes, los procesos que involucran actividades inherentes a la buena conservacin y/o estado de los productos en bodega y
los reglamentos para hacer efectivas las garantas. Si bien estos procesos no son parte directa de las ventas, intervienen indirectamente para
que stas sean llevadas a efecto con normalidad.
Por lo tanto, todos los procesos que forman parte del universo de posibilidades dentro del negocio, son importantes. Lo relevante es que, en
la etapa de anlisis, el analista o ingeniero sea capaz de darles la prioridad y relevancia necesaria para poder realizar en estricto rigor una
lista de ellas en orden de incidencia acorde a los procesos en estudio.

Ejemplo prctico: Proceso de devolucin de productos

El proceso de devolucin de productos tiene las siguientes acciones
relevantes, entre otras y dependiendo de la empresa:
Disponer del documento que acredite la fecha de compra
Revisar el estado del producto
Verificar que cumpla con el plazo establecido para hacer vlida la
garanta

Unidad 1: Introductorio

21

ANLISIS Y DISEO ORIENTADO A OBJETOS

Ante tal evento, el actor encargado de realizar el cambio o recibir la

devolucin del producto, necesariamente tendr interaccin con otros
procesos de validacin que le permitan dar por aprobado el evento.
Cabe destacar que este proceso no se afecta con el proceso de control
de calidad, pero de l es posible obtener informacin relevante que le
permita al otro proceso tomar acciones remediales, por ejemplo, para
evitar la misma incidencia nuevamente.

Cuando todos los antecedentes han sido analizados en el contexto adecuado, es posible realizar
un listado de los principales requerimientos y ordenarlos en funcin de las principales necesidades
acotadas por el cliente. Mediante este listado, ser posible formalizar las actividades que deben
ser realizadas para alcanzar dichos requerimientos.

El anlisis de requerimientos puede ser apoyado usando metodologas diseadas para hacer ms
fcil la tarea de captura.

Los sistemas han evolucionado tanto como las tecnologas que ellos utilizan, es por este motivo,
que las metodologas de desarrollo de software han migrado a plataformas que permiten al equipo desarrollador contar con una base de conocimiento que es posible utilizar, independiente del
enfoque que se quiera dar a la solucin.
Tradicionalmente se usaban esquemas de anlisis estructurado, lo que ha evolucionado a lo que
hoy se conoce como metodologas giles, que permiten el desarrollo de productos de software en
periodos cortos de tiempo, acoplndose perfectamente con las estructuras de orientacin a objetos que utilizan la mayora de los lenguajes de programacin actuales.

Unidad 1: Introductorio

22

ANLISIS Y DISEO ORIENTADO A OBJETOS

IDEAS FUERZA
El anlisis orientado a objetos toma sentido y fuerza a la hora de enfrentar problemticas y proponer alternativas de solucin. Cabe sealar que los trminos que involucran las metodologas
constituyen estndares, con el propsito de reunir la mayor cantidad de informacin a la hora de
realizar el anlisis previo.
En definitiva, la orientacin a objeto no es tan slo un concepto abstracto que debe ser aplicado
al desarrollo de soluciones, sino un conjunto de herramientas que permiten dar solucin en forma
lgica y precisa a un problema planteado.

El correcto anlisis de requisitos permitir, sin

duda, obtener el mximo de informacin de parte
del cliente.
Queda de manifiesto que las variadas tcnicas de recopilacin de informacin, no slo permiten
obtener datos directos desde el punto de vista tcnico, sino que adems, permiten visualizar el
esquema general del negocio estudiado y analizado.
Todas las alternativas posibles de solucin, deben estar sustentadas en los requerimientos del
cliente. El analista o ingeniero desarrollador, no puede dar por supuesta situaciones de acuerdo a
su preconcepcin del negocio, o bien porque ha adquirido experiencia en el rubro.
Utilizando herramientas de apoyo, es posible visualizar de manera esquemtica el problema,
permitiendo la elaboracin de documentos concretos, con el estudio en detalle de cada situacin
atendida en el estudio previo. Dicho anlisis puede ser esquematizado utilizando esos mecanismos
y dar con certeza una solucin ptima al cliente.

Unidad 1: Introductorio

23

ANLISIS Y DISEO ORIENTADO A OBJETOS

BIBLIOGRAFA
Booch, G. (1996). Anlisis y diseo orientado a objetos con aplicaciones. Segunda
edicin. Mxico: Prentice Hall.
Spark Systems. (2012). Tutorial UML 2.0: Diagrama de Tiempo UML 2. Disponible
en: http://www.sparxsystems.com.ar/resources/tutorial/uml2_timingdiagram.htm
Yourdon, E. (1998). Modern Structured Analysis. USA: Prentice Hall.
Bibliografa obligatoria
Fontela, C. (2011). UML: modelado de software para profesionales. Argentina, Buenos Ares: Alfaomega Grupo Editor.
Gutierrez, C. C. (2011). Casos prcticos de UML. Madrid, ES: Editorial Complutense.
Disponible en: http://site.ebrary.com/lib/inacapsp/detail.action?docID=10536104
&p00=Casos+pr%C3%A1cticos+de+UML
Vlez, S. J., Pea, A. A., & Gortazar, B. P. (2011). Disear y programar, todo es empezar: una introduccin a la Programacin Orientada a Objetos usando UML y Java.
Madrid, ES: Dykinson. Disponible en: http://site.ebrary.com/lib/inacapsp/detail.act
ion?docID=10559590&p00=Dise%C3%B1ar+y+programar%2C+todo+es+empezar%
3A+una+introducci%C3%B3n+a+la+programaci%C3%B3n+orientada+a+objetos+us
ando+UML+y+Java
Kimmel, P. (2002). Manual de UML. Mxico, D.F., MX: McGraw-Hill Interamericana.
Disponible en: http://site.ebrary.com/lib/inacapsp/detail.action?docID=10433806
&p00=UML%3A+modelado+de+software+para+profesionales
Casas, R. J., & Conesa, I. C. J. (2014). Diseo conceptual de bases de datos en UML.
Barcelona, ES: Editorial UOC. Disponible en: http://site.ebrary.com/lib/inacapsp/
detail.action?docID=10903566&p00=Dise%C3%B1o+conceptual+de+bases+de+da
tos+en+UML
Bennett, S. (2006). Anlisis y diseo orientado a objetos de sistemas usando UML.
Mxico D. F.: McGraw Hill.
Schach, S. R. (2006). Ingeniera de software clsica y orientada a objetos. Mxico D.
F.: McGraw Hill Interamericana
Bibliografa obligatoria
Sparx Systems. (2010). Introduction to enterprise architect, UML Modeling Tool.
Australia: Sparx Systems. Disponible en: http://www.sparxsystems.com/enterprise_architect_user_guide/9.3/introduction/introduction.html
Stevens, P. (2007) Utilizacin de UML en ingeniera del software con objetos y componentes. Espaa: Pearson Educacin.

Unidad 1: Introductorio

24