Tomará 5 preguntas aleatorias entre la unidad 1, 2 y 3. Para parcial 1.

Tomará 5 preguntas aleatorias entre la unidad 4, 5, 6, 7 y 8. Para parcial 2.

Guía de estudio Unidad 1° - Clase N° 1:

1) ¿Qué es un sistema de información?

Es un conjunto de acciones que generan información para cualquier uso que quiere hacerse de ella. Esas
acciones por lo general son: registrar, consultar, emitir y generar.
2) ¿Cuáles son sus componentes y qué diferencia hay con un Sistema informático?

3) ¿Qué es un modelo y para que se construye?

4) ¿En qué ayudan los modelos a los analistas?

5) ¿Cuáles son las características de los modelos?

- Deben ser gráficos con los detalles textuales apropiados.
- Deben permitir que el sistema sea visto en partes.
- Deben tener redundancia mínima.
- Deben ayudar al lector a predecir el comportamiento del sistema.
- Deben ser transparente para el lector, es decir que cuando lo vea no piense que se trata de una
representación, sino que el sistema mismo.
6) ¿Cuáles son las ventajas de utilizar modelos?
- Permiten concentrarnos en lo importante, enfatizando ciertas propiedades del sistema.
- Permiten discutir cambios a bajo costo. (Por ejemplo, si el cliente quiere cambiar algo del software
vamos a reducir tiempo modificando sobre un modelo, no el trabajo final).
- Ahorro de tiempo en preparación.
- Permiten analizar y experimentar situaciones complejas.
- Permiten verificar que el analista comprendió la petición del usuario.
- Permiten contar con la información documentada.

LUCIANA LISETTE MONTARCÉ 1

7) ¿Qué es el modelado de negocio?
Es una técnica para comprender los procesos de negocio de la organización. Muestra el ambiente de la
organización y cómo esta actúa en la relación con el ambiente.
8) ¿Por qué necesitamos el modelado de negocio?
Los modelos de negocio pueden ayudar a reducir riesgos y evitar errores. A medida que se modela el
negocio se aprende sobre el contexto del sistema.
Un modelo de negocio sirve para construir el SI. A lo cual se debe saber:
- Los usuarios (los recursos) dentro y fuera de la organización, quiénes usarán el SI.
- Todos los procesos de negocio.
- Tipos de documentos que reproducen mientras un proceso corre y que se hace con cada uno.

Guía de estudio Unidad 1° - Clase N° 2:

BPM o gestión del proceso Empresarial (Business process managment)

Es una metodología empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los
procesos de negocio, que se deben modelar, automatizar, integrar, monitorear y optimizar de forma continua.

BPMN

BPMN promueve

- Agregar valor al cliente.

- Incorporar el concepto de calidad en el proceso.
- Tener procesos controlados.
- Definir “algo” (la unidad de gestión y de costos) para medir el desempeño y la eficiencia.
- Posibilitar una certificación en normas de calidad ISO 9001/2008.
- Conocer lo que hacemos y cómo lo hacemos para mejorar continuamente

LUCIANA LISETTE MONTARCÉ 2

¿Por qué es importante modelar en BPMN?

- Es independiente de cualquier metodología de modelado de procesos, permite modelar los procesos de

manera unificada y estandarizada.
- Proporciona un lenguaje común para que las partes involucradas puedan comunicar los procesos de
forma clara, completa y eficiente.

¿Qué es la gestión de procesos?

Es una técnica que ayuda a los dueños de procesos a identificar, diseñar, formalizar, controlar, mejorar y hacer más
productivos los procesos de la organización para lograr la confianza del cliente. Es una totalidad (secuencia de
principio a fin) que cumple un objetivo completo, útil a la organización y agrega valor para el cliente.

¿Qué es macroproceso?

Los procesos se desagregan en otros procesos.

¿Qué es proceso operativo?

Es un proceso de bajo nivel que no se puede desagregar más como proceso, donde aparecen las actividades en el
flujograma de información.

Conceptos utilizados en la gestión de procesos:

- Procesos críticos o claves: son los vitales para el funcionamiento del negocio.
- Actividad: es una acción (cotizar, vender, tomar un pedido) que realizar un rol (persona o equipo) en un
periodo de tiempo.
- Tarea: es el desarrollo de una actividad en acciones muy específicas (poner en funcionamiento un
equipo, ingresar cada dato en un documento, realizar una llamada telefónica).
- Procedimiento: es una descripción detallada de una parte del hacer de la organización.
- Protocolo o instructivo: es un acuerdo interno mandatorio y específico, (forma de responder a una
llamada).
- Norma: es una estandarización con el medio mayor o menor grado de obligación. EJ: ISO. (Como una
norma más fuera del ambiente).

LUCIANA LISETTE MONTARCÉ 3

Tipos de procesos:

Proceso de estrategia:

Se dividen en estos pasos:

- Planificar: Realizar un proceso para obtener una estrategia.

- Implementar: Llevar a la realidad el plan estratégico, contemplando realizar, dirigir, asignar recursos,
supervisar la ejecución.
- Verificar: Medir y controlar que se siga el plan actualizado.
- Retroalimentar: Capturar el aprendizaje para incluir un nuevo ciclo del proceso de estrategia.

Proceso del negocio: Atiende a la misión de la empresa y se relaciona con el cliente. En cuanto más focalizada este la
organización, menor será el número de procesos del negocio.

Proceso de apoyo: Son las acciones necesarias para realizar las acciones del negocio, aquí caben los grandes
procesos como gestión y administración de personas, proyectos y otros.

Tipos de modelos para visualizar procesos:

- Mapa del proceso global: visión del conjunto ‘de helicópteros’ de todos los procesos de la organización.
Incluye los tres tipos de procesos que vimos. Permite conocer la totalidad y ubicarse en el contexto.

LUCIANA LISETTE MONTARCÉ 4

 - Mapa del ámbito: detalla una parte del proceso. El objetivo es desagregar hasta llegar al nivel de
procesos operativos (no se puede desagregar más). También llamado segmentación de procesos.

- Flujograma de información: por cada proceso operativo se dibuja un diagrama.

- Tareas de la actividad: descripción de la actividad.

Simbología de BPMN

LUCIANA LISETTE MONTARCÉ 5

Ejemplo de BPMN

Guía de estudio Unidad 2° - Clase N° 3:

Proceso de software:

LUCIANA LISETTE MONTARCÉ 6

 - Conjunto de actividades que conducen a la creación de un producto de software.
- Dependen de personas que toman decisiones y juicios. No existe proceso ideal
- Para los sistemas críticos, se requiere un proceso de desarrollo muy estructurado.
- Para sistemas de negocio con requerimientos rápidamente cambiantes, un proceso flexible, ágil
probablemente sea más efectivo.

Ingeniería de software:

Es el establecimineto y uso de principios robustos de la ingeniería a fin de obtener económicamente software que
sea fiable y que funcione eficientemente sobre máquinas reales.

Marco de trabajo:

Actividades genéricas que se llevan a cabo para construir y un poner en marcha un sistema de información:

LUCIANA LISETTE MONTARCÉ 7

 - Análisis: Atender el requerimiento del usuario, conocer la estructura formal de la organización, sus
políticas, etc. Realizar un diagnóstico, plantear el modelo lógico y hacer el estudio de factibilidad.
- Diseño: Establecer la frontera de automatización, asignar procesos a los procesadores, si se usa más de
una computadora explicar las formas de comunicación denominado ’Modelo arquitectónico’ y diseñar la
interfaz y el manual de usuario.
- Implementación:
o Construcción y prueba: programación y la prueba de sistema en forma experimental para
asegurar que no falle.
o Puesta en marcha o instalación: poner en uso la aplicación y construir las bases de datos
necesarios.
- Mantenimiento:
o Corrección: se corrigen los errores del sistema.
o Adaptación: se hacen cambios al software para cubrir cambios de sistema operativo, hardware,
etc.
o Mejora: el cliente puede descubrir funciones adicionales que sean de utilidad.

Estudio de factibilidad:

Factibilidad de los proyectos:

Se utiliza para analizar la necesidad, conveniencia y oportunidad de poner en funcionamiento un sistema, comando
o no con el equipamiento necesario.

Obtener una razonable seguridad acerca de la posibilidad del éxito de un proyecto comprende estudio de
factibilidades.

- Factibilidad técnica: implica la tecnología para llevar a cabo ese sistema que me pidieron, está disponible
en esa organización y si no la tienen ellos, si está disponible en el mercado.
- Factibilidad económica: comparar costos y beneficios.
- Factibilidad operativa: están involucradas las personas para la utilización del sistema. Por ejemplo: la
interfaz del usuario no le es práctica a la persona y no le ayuda en el trabajo. Al sistema lo tienen que
adecuar a las personas que lo van a usar.

Relación entre el marco de trabajo y las actividades genéricas:

- En la etapa análisis: relacionamos comunicación, planeación (factibilidad también) y modelado.

- En la etapa diseño: relacionamos modelado.
- En la etapa de implementación: relacionamos el despliegue. (aquí vamos depurando cosas que surgen a
necesidad, como pulir detalles).
- En la etapa de mantenimiento: (aquí es más una actualización anual a causa de, por ejemplo: el
ambiente ha cambiado y se necesita agregar cosas).

Definición de método: El método indica que tengo que hacer. Es una explicación.

LUCIANA LISETTE MONTARCÉ 8

Definición de técnica: La técnica es como tengo que hacer. Es un procedimiento de pasos a seguir.

Definición de herramienta: La herramienta nos dice con qué hacerlo.

Definición de metodología: es la implementación del método, la técnica y herramientas.

Importancia del uso de metodologías estandarizadas:

Ayudan a aumentar la productividad de los equipos de trabajo, simplificando la comunicación y permitiendo la

optimización de los tiempos por el uso de herramientas probadas,

Características de las metodologías:

- Ser completas
- Ser modificables en su corrección.
- Producir productos contras los que se pueda medir el avance del desarrollo del sistema.
- Ser fácilmente aprovechable cada producto generado en la fase subsiguiente.

Documentación:

Se documenta para:

- Comprender los compromisos que se asumen, las políticas que se definen y los riesgos que se corren.
- Comunicar la información de un sector a otro. Ej.: de diseñador a programador.
- Controlar las alternativas que sufre el proyecto y prevenir situaciones indeseables.
- Comunicar a los usuarios las decisiones del diseño.

¿Qué documentar?

TODO. Todas las decisiones, todo lo modelado.

¿Cuándo documentar?

A medida que se van haciendo las cosas, que se generan los documentos y que se toman las decisiones.

¿Quién documenta?

La documentación debe ser organizada, pulida, y hecha presentable. Generalmente el grupo de sistemas elige a una
persona que se encargará de recolectar la información, organizarla y difundir los documentos que se producen en el
equipo.

- Sin documentación no hay mantenimiento posible.

LUCIANA LISETTE MONTARCÉ 9

La calidad en el desarrollo de software: Es la concordancia de los requisitos funcionales estándares de desarrollo
documentado (criterios que guían el desarrollo) con características implícitas que se espera de todo sistema
desarrollado. Profesionalmente, por ejemplo: un buen mantenimiento.

La garantía de calidad es una actividad de protección que se aplica a cada paso del proceso de ingeniería de
software.

Factores que determinan la calidad:

- Fiabilidad.
- Facilidad de uso.
- Flexibilidad.
- Reusabilidad.
- Integridad: seguridad de datos.
- Facilidad de mantenimiento.
- Portabilidad.

Modelos de procesos de software:

- Proceso en cascada o clásico:

Características:
o Enfoque sistemático y secuencial en el desarrollo. Predecesor de todos los modelos de
desarrollo.
o Las etapas no se solapan.

LUCIANA LISETTE MONTARCÉ 10

 o Todos los requerimientos deben ser definidos al comienzo.
o No existe retroalimentación a etapas anteriores,
o Solo se ve el software al final del proceso.
- Modelo incremental:

- Modelo RDA

Características:
o Es un modelo de proceso incremental.
o Las etapas de un ciclo de vida tradicional son comprimidas a su máxima expresión, de forma que
el paso entre fases se lo debe hacer muy rápidamente e iniciar la próxima iteración.
o A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de
desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente dibujando y
colando iconos en la interfaz.
o Para su desarrollo se utilizan herramientas de desarrollo visual para aplicar el proceso.
o Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

¿Para qué es útil el prototipo?

Es útil para cuando el cliente no identifica detalladamente los objetivos y cuando en programador no está seguro de
la eficiencia del programa.

LUCIANA LISETTE MONTARCÉ 11

Si me manejo solo con el prototipo, como trabajo final, estoy sacrificando calidad.

- Modelo espiral

Características:

o Cubre las mejores características del ciclo de vida clásico y de prototipo.

o La toma de requerimientos se realiza durante todo el proyecto.
o El software se construye a partir de iteraciones en forma de espiral donde en cada vuelta se
construye una versión más completa del sistema.
o Se realiza el análisis de riesgo a lo largo de todo el proyecto.

- Método formal: es una técnica basada en matemáticas, usada para describir sistemas. Permiten
representar la especificación del software, verificación y diseño de componentes mediante notaciones
matemáticas.

Características:
o Estos modelos llevan mucho esfuerzo.
o Difícil especificar aspectos de interfaz
o Pocos desarrolladores dominan las matemáticas para esto.
- El modelo evolutivo desarrolla una nueva versión de todo el sistema, en el incremental se parte de la
versión anterior sin cambios y se le añaden las nuevas funciones.

LUCIANA LISETTE MONTARCÉ 12

 - El modelo incremental: entrega el software en partes pequeñas pero utilizables, llamadas incrementos,
En general cada incremento se construye sobre aquel que ya ha sido entregado.
- El modelo iterativo: Se entrega el esqueleto de un sistema completo desde el principio y luego cambia la
funcionalidad de cada subsistema con cada versión nueva.
- El modelo espiral: Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de
construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial.

Guía de estudio Unidad 2° - Clase N° 4:

¿Por qué es importante utilizar un proceso para desarrollar un SI?

- Es una guía para ordenar las actividades de un equipo.

- Dirige las tareas por separado para cada desarrollador y en conjunto.
- Específica los artefactos a desarrollarse.
- Ofrece criterios para el control y la medición de los productos y actividades del proyecto.

¿Qué es el PUD?

El proceso unificado es un proceso de desarrollo de software que nos dice los recursos humanos, las actividades y
artefactos que necesitamos utilizar, desarrollar o crear para modelar un sistema de software.

Características del PUD

- Está basado en componentes e interfaces bien definidas.

- Utilizar el lenguaje unificado de modelado (UML)
- Características típicas:

LUCIANA LISETTE MONTARCÉ 13

 o Dirigido por casos de usos: Para construir un sistema con éxito debemos conocer lo que nuestros
futuros usuarios necesitan. Por ello es caso de usos guía el diseño del sistema desde el inicio con el
análisis, pasando por el desarrollo la implementación y prueba. Se desarrollan a la vez que la
arquitectura del sistema.

o Centrado en la arquitectura: Simulando a la arquitectura de edificios, se describe mediante

diferentes vistas del sistema en construcción. Debe haber interacción entre los casos de uso y la
arquitectura. Deben evolucionar en paralelo. Una arquitectura ejecutable es una implementación
parcial del sistema, construida para demostrar algunas funciones y propiedades.

o Iterativo e incremental: Es práctico dividir el proyecto en partes mini proyectos, de estas pequeñas
iteraciones resultan de un incremento. En cada iteración los desarrolladores identifican los casos de
uso más relevantes.
Comprende: casos de uso y escenarios diseños de opciones de arquitectura, codificación y prueba,
evaluación en la entrega de cada ejecutable acompañado de su respectiva documentación.

Surgimiento de las metodologías agiles

El desarrollo de los enfoques rápidos prospero a fines de los 90’ con el desarrollo de la noción de enfoques rápido
con Stapleton 1997 – Scrum 2001 y programación extrema 2000. El término ágil, aplicado a software nace en 2001,
en una reunión celebrada en Utah, donde un grupo de 17 expertos de la industria de software tenían como objetivo,
ofrecer una alternativa a los procesos de desarrollo de software tradicionales, que se caracterizaban por ser rígidos y
dirigidos por documentación. Se creó la alianza agile.

LUCIANA LISETTE MONTARCÉ 14

Importancia: Se utilizan para producir rápidamente un software útil. Se desarrolla en mas de una unidad, como una
serie de incrementos y cada uno incluye uno de ellos una nueva funcionalidad.

Tiene éxito en el desarrollo de producto (pequeño o mediano para su venta) y en el diseño de sistemas a medida
dentro de una organización.

Las metodologías agiles tienen la particularidad de que el tiempo y los recursos (personas, materiales, equipos) son
fijos. En cambio, el conjunto de características y especificaciones del producto o servicio que se desea construir es
totalmente flexible, ajustable, cambiante.

El manifiesto ágil:

- Participación del cliente: ofrecer y priorizar nuevos requerimientos y evaluar las iteraciones.
- Entrega incremental: el cliente especifica los requerimientos que se van a incluir en cada incremento.
- Personas, no procesos: tienen que reconocerse y aprovecharse las habilidades del equipo de trabajo.
Permitir al equipo de su propia forma sin procesos establecidos.
- Adoptar el cambio: esperar a que cambien los requerimientos.
- Mantener simplicidad: tanto en el software a desarrollar como en el proceso de desarrollo.

Características de las metodologías agiles:

LUCIANA LISETTE MONTARCÉ 15

Problemas que surgen:

- Involucrar al cliente: debe desear y poder pasar tiempo con el equipo, además representan a todos los
participantes.
- Priorizar a los miembros del equipo de desarrollo: puede ser que no se adapten a la participación
intensa, si se pierde un integrante, se pierde conocimiento explicito.
- Mantener la simplicidad: bajo la presión de fechas de entrega es posible que los miembros del equipo
carezcan de tiempo para realizar las simplificaciones deseables.
- Acordar el contrato: Al no contar con la ERS puede ser difícil elaborar contratos. Si todo va bien beneficia
a ambas partes, pero cuando surgen problemas es más difícil establecer quien paga por el tiempo y
recursos extras.
- No documentar: tienen un difícil y costoso mantenimiento.

Guía de estudio Unidad 2° - Clase N° 5:

¿Por qué es difícil introducir metodologías agiles en grandes empresas?

- Falta de experiencia.
- Las grandes empresas tienen procedimientos y estándares de calidad que se espera que sigan todos los
proyectos.
- Resistencia cultural al cambio.

Sugerencias para que las metodologías agiles funcionen en sistemas grandes.

- No podemos centrarnos solo en el código es necesario documentar aspectos críticos, esquemas de bases
de datos, división del trabajo entre equipos.
- Deben diseñarse mecanismo de comunicación entre equipos.

SRUM

Usa equipos interfuncionales autoorganizados que dividen su trabajo en ciclos de trabajo cortos y
concentrados llamados sprints.

Equipos: roles

Scrum master: persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la
metodología y trabaja con el producto owner.

Product owner: representante de los clientes que usan el software. Se focalizan en la parte de negocio,
formaliza los requerimientos en historias de usuario a incorporar en el product backlog. El producto backlog(pila de
producto es una lista viva de requisitos priorizados por su valor para el cliente.

LUCIANA LISETTE MONTARCÉ 16

 Team: grupo de profesionales que desarrollan el proyecto de manera conjunta llevando a cabo las historias a
las que se comprometen al inicio de cada sprint.

SCRUM – Proceso

El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada sprint, tiene una duración
preestablecida de entre 2 y 4 semanas obteniendo como resultado una versión de software con nuevas
funcionalidades listas para ser usadas. En cada sprint, se va ajustando la funcionalidad ya construida y se añaden
nuevas prioridades siempre aquellas que aporten mayor valor de negocio.

Daily sprint meeting: reunión diaria del equipo de como máximo 15 min.

Demo retrospectiva: reunión al final del sprint y en la que el equipo presenta lo realizado mediante una
demostración del producto. Posteriormente, en la retrospectiva, el equipo analiza que se hizo bien, que mejorar.

SCRUM – Procesos y artefactos

Product backlog (pila de producto): conjunto de requisitos denominado historias de usuarios, escritos en un lenguaje
no técnico y priorizados por valor de negocio.

Sprint planning (planificación del sprint): reunión durante la cual el producto owner presenta las historias de
usuarios del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse
a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar como lo va conseguir.

Sprint backlog (pila de sprint): lista de las tareas necesarias para llevar a cabo las historias del sprint.

LUCIANA LISETTE MONTARCÉ 17

Guía de estudio Unidad 3° - Clase N° 5:

Concepto de paradigma

Es un conjunto de teorias, estandares y metodos que juntos representan una forma de organizar el conocimineto,
una forma de ver el mundo.

¿En que consiste la orientacion a objetos?

Es una metodología no algorítmica, identifica objetos que se comunican entre si haciéndose peticiones. Cada uno de
ellos encapsulan para si atributos, propiedades y un conjunto de operaciones. No hay ejecución procedimental de
tareas, sino que hay mensajes de un objeto a otro.

Tipos de software que se pueden desarrollar: software simple

Son aplicaciones específicas construidas y mantenidas por la misma persona. Tienen un propósito muy limitado y un
ciclo de vida corto. Uno puede darse el lujo de reemplazarlo completamente en lugar de reutilizarlos o extender su
funcionalidad.

Software complejo

Llamado también de dimensión industrial son aplicaciones que exhiben un conjunto muy rico de comportamientos.
Tienen ciclos de vida largos y son sumamente difíciles sino imposibles de hacer para el desarrollar sumamente
difíciles sino imposibles de hacer para el desarrollador individual. Llevan una inversión considerable por lo que no es
aceptable desechar un sistema cada vez que los requerimientos cambien.

LUCIANA LISETTE MONTARCÉ 18

¿Qué dificultades se pueden presentar en el desarrollo del software?

- Planificaciones estimación de costos frecuentemente imprecisos.

- Software que no corresponde con lo pedido.
- Calidad del software que no llega a ser ni aceptable.

Esos problemas planteados se producen por el propio carácter del software y por los errores de las personas
encargadas de su desarrollo, respecto a esto último:

- En algunos casos los responsables no tienen conocimiento del software.

- Todos nos resistimos al cambio
- Falta de entrenamiento respecto a las nuevas técnicas de desarrollo del software.

El rol de la descomposición

Cuando se diseñan sistemas complejos es esencial descomponerlo en partes, existen dos formas de hacerlo:

- Algorítmicas
- Orientada a objetos

Características de las técnicas orientada a objetos

- Cambia nuestra forma de pensar sobre los sistemas ya que es mas natural
- Los sistemas suelen construirse a partir de objetos ya existentes. Esto llevas a un alto grado de
reutilización, a un ahorro de dinero, un menor tiempo de desarrollo y una mayor confiabilidad del
sistema.
- La complejidad de los objetos que podemos utilizar sigue en aumento puesto que nuevos objetos se
construyen a partir de otros.
- Ayuda a explotar la potencia expresiva de los lenguajes de programación basados y orientados a objetos.

Clase y objeto

Una clase: es una abstracción de atributos y comportamientos comunes de un conjunto de objetos. Son los bloques
de construcción mas importantes de cualquier sistema orientado a objetos.

Vistas de una clase:

- Visión externa o interfaz: La interfaz oculta su estructura y secretos de su comportamiento.

LUCIANA LISETTE MONTARCÉ 19

 - Visión interna o implementación: La implementación de una clase es su visión interna que engloba los
secretos de su comportamiento.

La implementación de estas características dependerá de como maneje el lenguaje de programación elegido.

Representación y sintaxis de una clase

En UML las clases se representan mediante un rectángulo que puede estar dividido en tres partes.

- Nombre: siempre comienza con mayúscula.

- Atributos: son las propiedades, datos de los objetos que deseamos recordar. UML establece que se
escribe con minúscula, cuando hay mas de una palabra se separa por la 1° letra de la palabra siguiente
con mayúscula. Una clase puede tener muchos atributos o ninguno.
- Servicios/operaciones: es la implementación de un servicio que puede ser requerido a cualquier objeto
de la clase para muestre su comportamiento. UML establece que siempre se escribe con minúsculas,
cuando hay mas de una palabra separada por la 1° letra de la palabra siguiente con mayúsculas mas los
parámetros. Una clase puede tener cualquier número de operaciones o ninguno.

Un objeto: es una representación concreta de esa abstracción, llamado también instancia. Los objetos representan a
un elemento, unidad o entidad individual e identificable ya sea real o abstracta con un papel definido en el dominio
del problema.

Ejemplo:

Clase: Curso 2k2

- Martin
- Laura Instancias
- Joaquín
- …

Todo objeto tiene una estructura, es decir atributos (propiedades) y operaciones (son acciones que el objeto puede
hacer). Continuando el ejemplo anterior:

Objeto: Martin

LUCIANA LISETTE MONTARCÉ 20

 - Atributos: Altura, peso, edad, etc.
- Operaciones: Hablar, escribir, reír, etc.

Los objetos también tienen:

- Estado: abarcas todas las propiedades del mismo, mas los valores actuales de cada una de esas
propiedades. Está compuesto de datos, será uno o varios atributos a los que se le habrán asignado unos
valores concretos.
- Comportamiento: cómo actúa y reacciona un objeto en términos de sus cambios de estado y paso de
mensajes. Esta definido por los métodos que puede operar dicho objeto.
- Identidad: es aquella propiedad de un objeto que lo distingue de todos los demás. Es una propiedad que
lo distingue del resto.

Guía de estudio Unidad 3° - Clase N° 6:

Metodología orientada a objetos

Fue propuesta por Grady Booch y en ella propone que los sistemas pueden ser vistos como un conjunto de objetos o
entidades con una identidad y comportamiento propio, las cuales interactúan entre si para alcanzar el objetivo
común del sistema.

Cualquier modelo que carezca de algunos de estos 4 elementos no es orientación a objetos.

Elementos primarios del modelo de objetos:

- Abstracción: se centra en la visión externa de un objeto y sirve para separar el comportamiento de su

forma de implantación.
- Encapsulamiento: Se centra en la implementación que da lugar al comportamiento.
- Modularidad: consiste en fragmentar en componentes individuales que pueden compilarse
separadamente pero que tienen conexiones con otros módulos. Ofrece una vía para agrupar
abstracciones relacionadas lógicamente.
Agrupar las abstracciones en módulos cohesivos (que guarden cierta relación) y minimizar la
dependencia entre ellos (acoplar).
- Jerarquía: se trata de una forma de ordenar o clasificar las abstracciones, las dos jerarquías mas
importantes en un sistema (que forman la arquitectura de un sistema) complejo son:
o ES-UN llamada Herencia (estructura de clase): Ejemplo: un avión es un transporte.
o ES-parte-de llamada Agregación (estructura de objetos): Ejemplo: un motor es parte de un auto.

Elementos secundarios del modelo de objetos:

- Tipos (tipificación).
- Concurrencia.
- Persistencia.

Relaciones entre objetos

- Enlace: es una conexión física o conceptual entre instancias de objetos. El objeto cliente utiliza los
servicios del servidor. Un mensaje enviado de un objeto a otro representa un enlace.
- Agregación: denota jerarquía en la cual un objeto del todo, tiene objetivos de la parte, puede o no
denotar una contención física. Ejemplo: un avión se compone de alas, motor, etc. un accionista tiene
acciones, pero estas no son parte físicas de él.

Operación: es una implementación de un servicio que puede ser requerido a cualquier objeto de la clase para que
muestre su comportamiento.

LUCIANA LISETTE MONTARCÉ 21

Responsabilidad: incluye el conocimiento que un objeto mantiene las acciones que puede llevar a cabo; es una
descripción de lo que sus atributos y operaciones intentan realizar en conjunto.

Colaboración: representa una solicitud de un cliente a un servidor para cumplir una responsabilidad del cliente. Se
dice que el objeto B colabora con A, si A para cumplir con su responsabilidad necesita enviar algún mensaje a B
solicitándole un servicio.

Método: es una implementación de una operación.

Relaciones entre clases

- Generalización (herencia): representa una jerarquía de abstracción en la que una subclase hereda de una
(herencia simple) o más superclases (herencia múltiple), permite a los objetos construirse a partir de
otros objetos. La clase base contiene todas las características de la clase base mas las características
particulares de la subclase.
La herencia de las operaciones de una superclase permite que las clases compartan su código en vez de
volver a definirlo. Se representa con una flecha de punta blanca.

- Asociación: relación semántica es decir dos clases colaboran entre si para algo. La notación para las
asociaciones es una línea entre clases, no establece la forma exacta en que una clase se relaciona con
otra.

Dentro de la asociación tenemos la agregación “todo/parte”, o sea un obvjeto tiene objetos de la parte.
Se representa con una flecha en cuyo extremo tiene un rombo y del otro lado el sentido de la flecha.

LUCIANA LISETTE MONTARCÉ 22

 - Dependencia: es un refinamiento de una asociación, el cambio en un elemento puede afectar el otro que
lo utiliza. Se representa la relación con una flecha con líneas de puntos dirigida hacia la clase de la cual se
depende. Esto es claramente una relación de uso; si la clase utilizada cambia, la operación de la otra
clase puede verse también afectada, porque la clase utilizada puede presentar ahora una interfaz o
comportamiento diferente.

Ejemplo: Tarjeta se hace visible para pago porque un objeto de esta última clase recibirá como
parámetro de entrada para su operación “autorizar”, un objeto de la clase tarjeta.

Polimorfismo: Diferentes objetos reaccionan al mismo mensaje de modo diferente, en cada caso realizará una
operación diferente. (abrir caja, abrir cuenta, abrir puerta).

Multiplicidad: muestra la cantidad de objetos de una clase que se relaciona con otro objeto de otra clase. Se indica al
final de la línea de asociación.

LUCIANA LISETTE MONTARCÉ 23

Navegabilidad: Se indica con el sentido de la flecha en la relación. Le da el sentido en el que daré acceso a los datos.
La dirección de la navegación indica que clase es la que contiene la referencia hacia la otra. Determina “quien conoce
a quién”.

Ejemplo: para mostrar los datos completos de una factura necesito información del cliente.

Ejemplo: para mostrar un resumen de cuenta de un cliente es necesario que el cliente conozca la factura que le
corresponda.

Diagrama de clases

Muestra un conjunto de clases, interfaces, sus colaboraciones y relaciones. Se utilizan para modelar las vistas de
diseño de un sistema. Esta vista es estática y soporta los requisitos funcionales del sistema.

Para construirlo…

- Encontrar las clases

- Encontrar responsabilidades

LUCIANA LISETTE MONTARCÉ 24

 - Encontrar colaboraciones

Modelo de objetos del dominio

Un diagrama de clases se puede utilizar para modelar lógicas.

Punteros o referencias en el diagrama de clases

Son vínculos físicos entre objetos. Un atributo que en realidad esta referenciando a un objeto de otra clase y que
permiten la relación de asociación entre clases. Al usar un puntero hay que poner en las operaciones conocerx()

Guía de estudio Unidad 3° - Clase N° 7:

UML y sus características

El lenguaje unificado de modelado es un lenguaje estándar para escribir planos de software. NO es una
METODOLOGÍA.

UML es independiente del proceso, aunque para utilizarlo óptimamente se aconseja utilizar u proceso:

- Dirigido por los casos de uso

- Centrado en la arquitectura
- Iterativo e incremental

Visión general de UML

LUCIANA LISETTE MONTARCÉ 25

 - Visualizarlo: un modelo explícito facilita la comunicación. Existe un lenguaje especifico para desarrollarlo
y que otro desarrollador pueda interpretarlo.
- Especificar: construir modelos precisos y completos. Cubre todas las especificaciones de análisis, diseño
e implementación que deben realizarse al desarrollar un sistema grande.
- Construir: no es un lenguaje de programación visual pero sus modelos pueden conectarse de forma
directa a una gran cantidad de lenguajes de programación como Java, C++, Visual basic, etc.
- Documentar: requisitos, arquitectura, diseño código fuente, pruebas, prototipos, versiones.

Elementos principales de UML

• Bloques de construcción:
- Elementos: Bloques básicos de construcción orientada a objetos. Se utilizan para escribir modelos bien
formados.
- Diagramas: Se dividen en diagramas de estructura y diagramas de comportamiento
- Relaciones: Se clasifican en, dependencia, asociación, generalización y realización
• Reglas: pautas para obtener modelos bien formados y en armonía con otros.
- Reglas semánticas: Nombres (como llamar a los elementos y relaciones), alcance (contexto de los
nombres), visibilidad (como se ven y utilizan), integridad (relaciones consistentes) y ejecución (simular el
modelo).
• Contemplan las reglas, la construcción de modelos:
- Abreviados: ciertos elementos se ocultan para simplificar.
- Incompletos: puede ausentar elementos iniciales del desarrollo.
- Inconsistentes: no se garantiza la integridad del modelo.

• Mecanismos comunes de UML:

- Especificaciones: en cada elemento de notación gráfica hay especificación que proporciona una
explicación textual.

LUCIANA LISETTE MONTARCÉ 26

 - Adornos: Todos los elementos comienzan con un símbolo básico al cual pueden añadirse una variedad
de adornos específicos de ese símbolo. Ej.: símbolos que indican la visibilidad de los atributos (público,
privado, protegido).
- Divisiones comunes: describen formas particulares.
- Mecanismos de extensibilidad: Puede no ser suficiente para expresar los matices posibles de todos los
modelos, por eso es posible extender el lenguaje con estos mecanismos:
o Estereotipos: Crear nuevos tipos de bloques de construcción, que derivan de los existentes.
o Valores etiquetados: extiende las propiedades de un bloque de construcción, permitiendo
agregar nueva información en las especificaciones de ese elemento.
o Restricciones: extiende la semántica de un bloque de construcción permitiendo agregar nuevas
reglas o modificando las existentes.

¿Por qué es necesaria la arquitectura?

Se necesita para comprender el sistema, organizar el desarrollo, fomentar la reutilización y hacer evolucionar el
sistema.

Vistas de un sistema con UML: modelado de la arquitectura

- Vista de casos de uso: describen el comportamiento del sistema tal y como es percibido por los usuarios
finales, analistas, y encargados de las pruebas,
- Vista de diseño: comprende las clases, interfaces y colaboraciones que forman el vocabulario del
problema y las soluciones.
- Vista de procesos: comprende los hilos y procesos que forman los mecanismos de sincronización y
concurrencia del sistema.
- Vista de implementación: comprende los componentes y archivos que se utilizan para ensamblar hacer
disponibles el sistema físico.
- Vista de despliegue: contiene los nodos que forman la topología hardware sobre la que se ejecuta el
sistema.

LUCIANA LISETTE MONTARCÉ 27