Fundamentos del Enfoque orientado a

Objetos.
I
El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base
de todo desarrollo orientado a objetos. Estos principios son: la Abstraccin, el
Encapsulamiento, la Modularidad y la Herencia.

Fundamento 1: Abstraccin

Es el principio de ignorar aquellos aspectos de un fenmeno observado que no son

relevantes, con el objetivo de concentrarse en aquellos que si lo son. Una abstraccin denota
las caractersticas esenciales de un objeto (datos y operaciones), que lo distingue de otras
clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio,
es el problema central del diseo orientado a objetos.
Los mecanismos de abstraccin son usados en el EOO para extraer y definir del medio a
modelar, sus caractersticas y su comportamiento. Dentro del EOO son muy usados
mecanismos de abstraccin: la Generalizacin, la Agregacin y la clasificacin.
La generalizacin es el mecanismo de abstraccin mediante el cual un conjunto de clases de

objetos son agrupados en una clase de nivel superior (Superclase), donde las semejanzas de
las clases constituyentes (Subclases) son enfatizadas, y las diferencias entre ellas son
ignoradas. En consecuencia, a travs de la generalizacin, la superclase almacena datos
generales de las subclases, y las subclases almacenan slo datos particulares.La
especializacin es lo contrario de la generalizacin. Por ejemplo; La clase Mdico es una
especializacin de la clase Persona, y a su vez, la clase Pediatra es una especializacin de la
superclase Mdico.
La agregacin es el mecanismo de abstraccin por el cual una clase de objeto es definida a

partir de sus partes (otras clases de objetos). Mediante agregacin se puede definir por
ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos
perifricos. El contrario de agregacin es la descomposicin.
La clasificacin consiste en la definicin de una clase a partir de un conjunto de objetos que

tienen un comportamiento similar. La ejemplificacin es lo contrario a la clasificacin, y

corresponde a la instanciacin de una clase, usando el ejemplo de un objeto en particular.

Fundamento 2: Encapsulamiento

Es la propiedad del EOO que permite ocultar al mundo exterior la representacin interna
del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del
mismo no son conocidos fuera de l. La idea central del encapsulamiento es esconder los
detalles y mostrar lo relevante. Permite el ocultamiento de la informacin separando el
aspecto correspondiente a la especificacin de la implementacin; de esta forma, distingue el
"qu hacer" del "cmo hacer". La especificacin es visible al usuario, mientras que la
implementacin se le oculta. El encapsulamiento en un sistema orientado a objeto se
representa en cada clase u objeto, definiendo sus atributos y mtodos con los
siguientes modos de acceso:
Pblico (+): Atributos o Mtodos que son accesibles fuera de la clase. Pueden ser llamados

por cualquier clase, aun si no est relacionada con ella.

Privado (-): Atributos o Mtodos que solo son accesibles dentro de la implementacin de la

clase.
Protegido (#): Atributos o Mtodos que son accesibles para la propia clase y sus clases hijas

(subclases).
Los atributos y los mtodos que son pblicos constituyen la interfaz de la clase, es
decir, lo que el mundo exterior conoce de la misma.Normalmente lo usual es que se oculten
los atributos de la clase y solo sean visibles los mtodos, incluyendo entonces algunos de
consulta para ver los valores de los atributos. El mtodo constructor (Nuevo, New) siempre es
Pblico.
Fundamento 3: Modularidad
Es la propiedad que permite tener independencia entre las diferentes partes de un
sistema. La modularidad consiste en dividir un programa en mdulos o partes, que pueden ser
compilados separadamente, pero que tienen conexiones con otros mdulos. En un mismo
mdulo se suele colocar clases y objetos que guarden una estrecha relacin. El sentido de
modularidad est muy relacionado con el ocultamiento de informacin.
Fundamento 4: Herencia
Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas
en otra clase que lo preceda en una jerarqua de clasificaciones. Permite la definicin de un
nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programacin
Diferencial), evitando repeticin de cdigo y permitiendo la reusabilidad.
Las clases heredan los datos y mtodos de la superclase. Un mtodo heredado puede
ser sustituido por uno propio si ambos tienen el mismo nombre. La herencia puede ser simple
(cada clase tiene slo una superclase) o mltiple (cada clase puede tener asociada varias
superclases). La clase Docente y la clase Estudiante heredan las propiedades de la clase

Persona (superclase, herencia simple). La clase Preparador (subclase) hereda propiedades

de la clase Docente y de la clase Estudiante (herencia mltiple).
Fundamento 5: Polimorfismo
Es una propiedad del EOO que permite que un mtodo tenga mltiples implementaciones,
que se seleccionan en base al tipo objeto indicado al solicitar la ejecucin del mtodo. El
polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual
nombre a diferentes clases o estn relacionados en trminos de inclusin. En este tipo de
polimorfismo, los mtodos son interpretados en el contexto del objeto particular, ya que los
mtodos con nombres comunes son implementados de diferente manera dependiendo de
cada clase.
Por ejemplo, el rea de un cuadrado, rectngulo y crculo, son calculados de manera
distinta; sin embargo, en sus clases respectivas puede existir la implementacin del rea bajo
el nombre comn rea. En la prctica y dependiendo del objeto que llame al mtodo, se usar
el cdigo correspondiente.
Ejemplos:
Superclase: Clase Animal
Subclases: Clases Mamfero, Ave, Pez.
Se puede definir un mtodo Comer en cada subclase, cuya implementacin cambia de
acuerdo a la clase invocada, sin embargo el nombre del mtodo es el mismo.
Mamifero.Comer Ave.Comer Pez.Comer
Otro ejemplo de polimorfismo es el operador +. Este operador tiene dos funciones
diferentes de acuerdo al tipo de dato de los operandos a los que se aplica. Si los dos
elementos son numricos, el operador + significa suma algebraica de los mismos, en cambio
si por lo menos uno de los operandos es un String o Carcter, el operador es la concatenacin
de cadenas de caracteres.

Caractersticas del Enfoque Orientado

a Objetos.
Las caractersticas siguientes son las ms importantes:
Abstraccin: Denota las caractersticas esenciales de un objeto, donde se capturan sus

comportamientos.Cada objeto en el sistema sirve como modelo de un "agente" abstracto que

puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el
sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o
los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son
requeridas para ampliar una abstraccin.El proceso de abstraccin permite seleccionar las

caractersticas relevantes dentro de un conjunto e identificar comportamientos comunes para

definir nuevos tipos de entidades en el mundo real. La abstraccin es clave en el proceso de
anlisis y diseo orientado a objetos, ya que mediante ella podemos llegar a armar un
conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse

pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar
la cohesin de los componentes del sistema. Algunos autores confunden este concepto con el
principio de ocultacin, principalmente porque se suelen emplear conjuntamente.

Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicacin

en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan
independiente como sea posible de la aplicacin en s y de las restantes partes. Estos
mdulos se pueden compilar por separado, pero tienen conexiones con otros mdulos. Al
igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas.

Principio de ocultacin: Cada objeto est aislado del exterior, es un mdulo natural, y cada

tipo de objeto expone una interfaz a otros objetos que especfica cmo pueden interactuar con
los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su
modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos
internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden
cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos
secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un
acceso directo a los datos internos del objeto de una manera controlada y limitando el grado
de abstraccin. La aplicacin entera se reduce a un agregado o rompecabezas de objetos.

Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden compartir

el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente

al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de
objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en
una referencia producir el comportamiento correcto para el tipo real del objeto referenciado.
Cuando esto ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin
tarda o asignacin dinmica. Algunos lenguajes proporcionan medios ms estticos (en
"tiempo de compilacin") de polimorfismo, tales como las plantillas y la sobrecarga de
operadores de C++.

 Herencia: Las clases no estn aisladas, sino que se relacionan entre s, formando una

jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas

las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el
encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados
de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener
que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en
clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un
objeto hereda de ms de una clase se dice que hay herencia mltiple.

Recoleccin de basura: La recoleccin de basura o garbage collector es la tcnica por la cual

el entorno de objetos se encarga de destruir automticamente, y por tanto desvincular la

memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto
significa que el programador no debe preocuparse por la asignacin o liberacin de memoria,
ya que el entorno la asignar al crear un nuevo objeto y la liberar cuando nadie lo est
usando. En la mayora de los lenguajes hbridos que se extendieron para soportar el
Paradigma de Programacin Orientada a Objetos como C++ u Object Pascal, esta
caracterstica no existe y la memoria debe desasignarse manualmente.

Fundamentos del Enfoque Orientado a Objetos 2

Componentes fundamentales del

Enfoque Orientado a Objetos.
Clase: Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La

instanciacin es la lctura de estas definiciones y la creacin de un objeto a partir de ellas.

Herencia: (Por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la

clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y
operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos
mtodos y variables publicas declaradas en C. Los componentes registrados como "privados"
(private) tambin se heredan, pero como no pertenecen a la clase, se mantienen escondidos
al programador y slo pueden ser accedidos a travs de otros mtodos pblicos. Esto es as
para mantener hegemnico el ideal de OOP.

 Objeto: Entidad provista de un conjunto de propiedades o atributos (datos) y de

comportamiento o funcionalidad (mtodos) los mismos que consecuentemente reaccionan a

eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos
del sistema (del programa). Es una instancia a una clase.

Mtodo: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se

desencadena tras la recepcin de un "mensaje". Desde el punto de vista del comportamiento,
es lo que el objeto puede hacer. Un mtodo puede producir un cambio en las propiedades del
objeto, o la generacin de un "evento" con un nuevo mensaje para otro objeto del sistema.

Evento: Es un suceso en el sistema (tal como una interaccin del usuario con la mquina, o un

mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado
al objeto pertinente. Tambin se puede definir como evento, a la reaccin que puede
desencadenar un objeto, es decir la accin que genera.

Mensaje: Una comunicacin dirigida a un objeto, que le ordena que ejecute uno de sus
mtodos con ciertos parmetros asociados al evento que lo gener.

Propiedad o atributo: Contenedor de un tipo de datos asociados a un objeto (o a una clase

de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus
caractersticas predeterminadas, y cuyo valor puede ser alterado por la ejecucin de algn
mtodo.

Estado interno: Es una variable que se declara privada, que puede ser nicamente accedida
y alterada por un mtodo del objeto, y que se utiliza para indicar distintas situaciones posibles
para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de
la clase.

Componentes de un objeto: Atributos, identidad, relaciones y mtodos.

Identificacin de un objeto: Un objeto se representa por medio de una tabla o entidad que
est compuesta por sus atributos y funciones correspondientes.

Reusabilidad de componentes.
Una vez que una clase ha sido escrita, creada y depurada, se puede distribuir a otros
programadores para utilizar en sus propios programas. Esta propiedad se llama reusabilidad
o reutilizacin. Su concepto es similar a las funciones incluidas en las bibliotecas de funciones
de un lenguaje procedimental como C que se pueden incorporar en diferentes programas. En
C++, el concepto de herencia proporciona una extensin o ampliacin al concepto de
reusabilidad.
Un programador puede considerar una clase existente y sin modificarla, aadir
competencias y propiedades adicionales a ella. Esto se consigue derivando una nueva clase
de una ya existente. La nueva clase heredar las caractersticas de la clase antigua, pero es
libre de aadir nuevas caractersticas propias.
La facilidad de reutilizar o rehusar el software existente es uno de los grandes
beneficios de la POO: muchas empresas consiguen con la reutilizacin de clase en nuevos
proyectos la reduccin de los costes de inversin en sus presupuestos de programacin. Las
propiedades comunes de varias clases slo necesitan ser implementadas una vez y slo
necesitan modificarse una vez si es necesario

Estadres en el Proceso de Desarrollo

de Software
La gran cantidad de organizaciones de desarrollo de software implementan
metodologas para el proceso de desarrollo. Muchas de estas organizaciones
pertenecen a la industria armamentstica, que en los Estados Unidos necesita un
certificado basado en su modelo de procesos para poder obtener un contrato.
El estndar internacional que regula el mtodo de seleccin,
implementacin y monitoreo del ciclo de vida del software es ISO 12207.
Durante dcadas se ha perseguido la meta de encontrar procesos reproducibles y
predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones
intentan sistematizar o formalizar la aparentemente desorganizada tarea de

desarrollar software. Otros aplican tcnicas de gestin de proyectos para la

creacin del software. Sin una gestin del proyecto, los proyectos de software
corren el riesgo de demorarse o consumir un presupuesto mayor que el planeado.
Dada la cantidad de proyectos de software que no cumplen sus metas en trminos
de funcionalidad, costes o tiempo de entrega, una gestin de proyectos efectiva es
algo que a menudo falta.
Planificacin.
La importante tarea a la hora de crear un producto de software es obtener
losrequisitos o el anlisis de los requisitos. Los clientes suelen tener una idea ms
bien abstracta del resultado final, pero no sobre las funciones que debera cumplir
el software. Una vez que se hayan recopilado los requisitos del cliente, se debe
realizar un anlisis del mbito del desarrollo. Este documento se conoce como
especificacin funcional.
Implementacin, pruebas y documentacin.
La implementacin es parte del proceso en el que los ingenieros de
softwareprograman el cdigo para el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del
software. Esta parte del proceso tiene la funcin de detectar los errores de
software lo antes posible.
La documentacin del diseo interno del software con el objetivo de facilitar
su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir
la documentacin de un API, tanto interior como exterior.
Despliegue y mantenimiento.
El despliegue comienza cuando el cdigo ha sido suficientemente probado,
ha sido aprobado para su liberacin y ha sido distribuido en el entorno de
produccin.
Entrenamiento y soporte para el software es de suma importancia y algo
que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza,
se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es
fundamental instruir de forma adecuada a los futuros usuarios del software.
El mantenimiento y mejora del software de un software con problemas
recientemente desplegado puede requerir ms tiempo que el desarrollo inicial del
software. Es posible que haya que incorporar cdigo que no se ajusta al diseo

original con el objetivo de solucionar un problema o ampliar la funcionalidad para

un cliente. Si los costes de mantenimiento son muy elevados puede que sea
oportuno redisear el sistema para poder contener los costes de mantenimiento.

Metodologa Empleada
El modelo y diseo orientado a objetos u OMT( tcnica de modelado de objetos ) se
extiende desde el anlisis hasta la implementacin pasando por el diseo . Actualmente es
una de las metodologas mas implantadas.

Las tcnicas orientadas a objetos permiten que el software se construya a partir de

objetos de compartimiento especifico.

Los propios objetos se pueden constituir a partir de otros , que a su vez pueden estar
formados por otros objetos .Esto nos recuerda a una maquina compleja construida por partes ,
subpartes y sub-subpartes,etc.

La metodologa de desarrollo de software orientada a objetos es cada da ms usada,

pues permite desarrollar software fcilmente extensible y reusable. Esto ltimo es slo posible
si los desarrolladores conocen muy bien los fundamentos que est basada esta metodologa.

Por eso, este curso revisa los conceptos ms importantes que se encuentran en las
distintas etapas del desarrollo de software orientado a objetos.

Fases y Disciplinas:

1. Establece oportunidad y alcance

2. Identifica las entidades externas o actores con las que se trata
3. Identifica los casos de uso
4. RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

5. 'Proceso': Las etapas de esta seccin son: (Revise nuevamente la grfica)

6. Modelado de negocio
7. Requisitos
8. Anlisis y Diseo
9. Implementacin
10. Pruebas
11. Despliegue
12. Soporte: En esta parte nos encontramos con las siguientes etapas:
13. Gestin del cambio y configuraciones
14. Gestin del proyecto
15. Entorno
16. La estructura dinmica de RUP es la que permite que ste sea un proceso de
desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases
descritas anteriormente:
17. Inicio(Tambin llamado Incepcin o Concepcin)
18. Elaboracin
19. Desarrollo(Tambin llamado Implementacin, Construccin)
20. Cierre (Tambin llamado Transicin)

Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto
con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una
visin muy general de la arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores

Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que

permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se
realiza la especificacin de los casos de uso seleccionados y el primer anlisis del
dominio del problema, se disea la solucin preliminar.

Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del

sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios
de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras
para el proyecto.

Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible
para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe
verificar que el producto cumpla con las especificaciones entregadas por las personas
involucradas en el proyecto.

Proceso Unificado de Desarrollo

El Proceso Unificado es un proceso de software genrico que puede ser utilizado para
una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin,
diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de
proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y resposabilidades dentro
de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta
calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y
presupuesto predecible.

El Proceso Unificado tiene dos dimensiones (Figura 1):

Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida
del proceso a lo largo de su desenvolvimiento

Un eje vertical que representa las disciplinas, las cuales agrupan actividades de
una manera lgica de acuerdo a su naturaleza.

La primera dimensin representa el aspecto dinmico del proceso conforme se va

desarrollando, se expresa en trminos de fases, iteraciones e hitos (milestones).
La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en
trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y
roles.

Cada fase representa un ciclo de desarrollo en la vida de un producto de software.

1. La fase de concepcin o inicio tiene por finalidad definir la visin, los objetivos y el
alcance del proyecto, tanto desde el punto de vista funcional como del tcnico,
obtenindose como uno de los principales resultados una lista de los casos de uso y
una lista de los factores de riesgo del proyecto. El principal esfuerzo est radicado en

el Modelamiento del Negocio y el Anlisis de Requerimientos. Es la nica fase que no

necesariamente culmina con una versin ejecutable.
2. La fase de elaboracin tiene como principal finalidad completar el anlisis de los casos
de uso y definir la arquitectura del sistema, adems se obtiene una aplicacin
ejecutable que responde a los casos de uso que la comprometen. A pesar de que se
desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se
hacen sobre la base de la comprensin del sistema completo y los requerimientos
(funcionales y no funcionales) identificados de acuerdo al alcance definido.
3. La fase de construccin est compuesta por un ciclo de varias iteraciones, en las
cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los
factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma
temprana con versiones el sistema que satisfacen los principales casos de uso. Los
cambios en los requerimientos no se incorporan hasta el inicio de la prxima iteracin.
4. La fase de transicin se inicia con una versin beta del sistema y culmina con el
sistema en fase de produccin.
Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de

cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas
fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias
iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incrementodel
producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos,
Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi
todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del
proyecto.

Dirigido por casos de uso

Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un
sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos.

El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas.
En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema
por desarrollar.

Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un

resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos
de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad
completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del
sistema. Una especificacin funcional tradicional se concentra en responder la pregunta: Qu
se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida
agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen
una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no
solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos
de uso no son solamente una herramienta para especificar los requerimientos del sistema,
tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de
desarrollo.

An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son
desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la

arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de
uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el
ciclo de vida.

Centrado en la arquitectura

El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto

desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de
vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver una
radiografa completa antes de empezar a construir. Similarmente, la arquitectura en un
sistema de software es descrita como diferentes vistas del sistema que est siendo
construido.

El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms

significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como
las interpretan los usuarios y otros stakeholders, y tal y como estn reflejadas en los casos de
uso. Sin embargo, tambin est influenciada por muchos otros factores, tales como la
plataforma de software en la que se ejecutar, la disponiblidad de componentes reutilizables,
consideraciones de instalacin, sistemas legados, requerimientos no funcionales (ej.
desempeo, confiabilidad). La arquitectura es la vista del diseo completo con las
caractersticas ms importantes hechas ms visibles y dejando los detalles de lado. Ya que lo
importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de
la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al
arquitecto a enfocarse en las metas correctas, tales como claridad (understandability),
flexibilidad en los cambios futuros (resilience) y reuso.

Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin y
forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para
obtener un producto exitoso. En este caso funcin corresponde a los casos de uso y forma a
la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un
problema del huevo y la gallina. Por una parte, los casos de uso deben, cuando son
realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer
espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la realidad,
ambos arquitectura y casos de uso deben evolucionar en paralelo.

Introduccin al Modelado

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la
actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico
para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como
procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para

describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en
el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est
descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para

dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado
Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar.

UML es el sucesor de la ola de mtodos de A y DOO que

aparecieron a finales de los 80 y principios de los 90

UML unifica principalmente los mtodos de Booch, Rumbaught

(OMT) y Jacobson. Pero pretende dar una visin ms amplia de

los mismos

UML est en proceso de estandarizacin por el OMG (Object

Management Group) [OMG]

UML es un lenguaje de modelado, no un mtodo.

Un mtodo incluye

Lenguaje de modelado: Es la notacin (en su mayora grfica) que

utilizan los mtodos para expresar los diseos.

Proceso: Son los pasos que se aconsejan dar para realizar un diseo.

Descarga Aqu PDF "Introduccion al UML"

Diagramas

- Casos de Uso

- Clases
- Objetos
- Secuencia
- Colaboracin
- Estados
- Actividades
- Componentes
- Despliegues

Descarga Aqu PDF "Diagramas UML"

Smbolos y Notacin

Herramientas Case

Conceptos Fundamentales sobre Herramientas

Case

Herramienta CASE segn ...

Henry David Crockett (Portland State University), "Las herramientas CASE se ven
simplemente como herramientas que cualquiera puede escoger y utilizar (como un martillo)
para desarrollar un sistema de informacin, su seleccin e implementacin casi siempre
llevar a una reducida productividad y calidad. La seleccin e implementacin de herramientas
CASE son un proceso de mltiples etapas que permite errores fatales en cada etapa. Uno de

los errores ms comunes es escoger una herramienta CASE que apoye un mtodo
desconocido para los diseadores".

Alan Chimura (CASE Associates), "Las herramientas CASE incluyen manejadores,

mtodos, tcnicas, disciplina, e instrucciones, todos trabajando juntos. Definir CASE menos
ampliamente y presentarlo sin un suficiente entorno de apoyo es un acto de negligencia".

Las herramientas CASE abarcan cada etapa del proceso de ingeniera y cada actividad
que se desarrolla a lo largo del mismo. CASE est formado por un conjunto de bloques que
comienzan en el nivel del hardware y del sistema operativo y acaban en cada una de las
herramientas.

CASE se refiere a herramientas para el desarrollo de sistemas que constan de cinco

componentes: herramientas de diagramacin, depsito de informacin, generadores de
interfaces, generadores de cdigo y herramientas de administracin. Las herramientas CASE
hacen hincapi en las actividades de alto nivel, aunque el objetivo a largo plazo es abarcar las
actividades de anlisis, diseo y desarrollo.

En resumen, las herramientas CASE son un complemento de la caja de herramientas

del ingeniero del software. CASE proporciona al ingeniero la posibilidad de automatizar
actividades manuales y de mejorar su visin general de la ingeniera. Al igual que las
herramientas de ingeniera y de diseo asistidos por computadora que utilizan los ingenieros
de otras disciplinas. Las herramientas CASE ayudan a asegurar la calidad de un producto
desde su diseo antes de construirlo.

Bloques bsicos de CASE

La ingeniera del software asistida por computadora puede ser tan sencilla como una
nica herramienta que preste su apoyo para una nica actividad de ingeniera del software, o
bien puede ser tan compleja como todo un entorno que abarque herramientas, una base de
datos, personas, hardware, una red, sistemas operativos, estndares, y otros muchos
componentes ms.

Los bloques de construccin de CASE

Cada bloque de construccin forma un fundamento para el siguiente, estando las
herramientas situadas en la parte superior de la estructura de los niveles de Hardware y
Software. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos
tiene relativamente poco que ver con las herramientas de ingeniera del software en s. Ms
bien, los entornos que tienen xito para la ingeniera del software se construyen basndose en
una arquitectura de entorno que abarca un hardware y un sistema software adecuado.
Adems, la arquitectura del entorno debe considerar patrones de trabajo humano que se
aplican durante el proceso de ingeniera de software. La arquitectura del entorno debe de
considerar los patrones de trabajo humano que se aplicaran durante el proceso de ingeniera
del software. Las arquitecturas del entorno constan de una plataforma hardware y de un apoyo
de sistema operativo (incluyendo el software de red y de gestin de la base de datos),
constituyen los fundamentos de CASE. Aunque su entorno en si requiere de otros bloques de

construccin, existe un conjunto de servicios de portabilidad que proporciona un puente entre

las herramientas CASE y su marco de referencia de integracin y la arquitectura del entorno.

El marco de referencia de integracin es una coleccin de programas ms especializados

que capacitan a las herramientas CASE individuales para comunicarse entre s, para crear
una base de datos del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero
del software). Los servicios de portabilidad permiten que las herramientas CASE y su marco
de referencia de integracin, migren entre distintas plataformas del hardware y sistemas
operativos sin un mantenimiento adaptativo que resulte significativo.

Los bloques de construccin representan un fundamento exhaustivo para la integracin

de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE utilizados
actualmente no han sido construidas empleando todos los bloques de construccin que antes
descritos. De hecho, algunas herramientas CASE siguen siendo soluciones puntuales. Esto
es, se utiliza una herramienta para que preste apoyo en una actividad de ingeniera del
software concreta (p. ej.: anlisis y modelado), pero esta herramienta no se comunica
directamente con otras. Es decir, no esta unida a una base de datos del proyecto y no forma
parte de un entorno integrado CASE (I-CASE), an cuando no es lo ideal, se puede utilizar
una herramienta CASE lo suficientemente eficiente, aunque se trate de una solucin puntual.

Algunas Herramientas CASE

Las herramientas CASE pueden clasificarse por su funcin, su papel como instrumentos
para administradores o personal tcnico, por su utilizacin en los distintos pasos del proceso
de ingeniera del software, la arquitectura de entorno (hardware y software) que les presta su
apoyo, o incluso por su origen o su coste. En muchos casos, las nicas herramientas

disponibles para el ingeniero del software eran compiladores y editores de texto. Estas
herramientas abarcan solo la codificacin, actividad que no debera de ocupar mas del 20%
del proceso global del software.

No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil

incluirlas en una clase determinada. Podran clasificarse atendiendo a:

- Las plataformas que soportan.

- Las fases del ciclo de vida del desarrollo de sistemas que cubren.

- La arquitectura de las aplicaciones que producen.

- Su funcionalidad.

CASE es una combinacin de herramientas software (aplicaciones) y de metodologas de

desarrollo :

1. Las herramientas permiten automatizar el proceso de desarrollo del software.

2. Las metodologas definen los procesos automatizar.

Una primera clasificacin del CASE es considerando su amplitud :

TOOLKIT: es una coleccin de herramientas integradas que permiten automatizar un conjunto

de tareas de algunas de las fases del ciclo de vida del sistema informtico: Planificacin
estratgica, Anlisis, Diseo, Generacin de programas.

WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la

automatizacin del proceso completo de desarrollo del sistema informtico. Permiten cubrir el

ciclo de vida completo. El producto final aportado por ellas es un sistema en cdigo ejecutable
y su documentacin.
Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que
automatizan:

UPPER CASE: Planificacin estratgica, Requerimientos de Desarrollo Funcional de Planes

Corporativos.

MIDDLE CASE: Anlisis y Diseo.

LOWER CASE: Generacin de cdigo, test e implantacin

"Herramientas CASE"