Listado de cases de Bases de datos y sus temas

 Listado de clases de Sistemas de Bases de Datos

Clase

Clases de 02/04

Clase

Clase

Temas:

Claves foráneas.

Clase

Clase

Clase

Clase

Clase

Clase

Clase

Clase

Clase

Clase

Operador JOIN - Junta natural

Clase

Clase

Clase

Clase

Clase

Clase

El comando ls

El comando ls enumera el contenido y la información opcional de los directorios y archivos. Al ejecutarlo sin opciones, lista los archivos contenidos en el directorio actual, clasificándolos alfabéticamente

Sintaxis

ls [ opción …] [ archivo o directorio ]

Opciones del comando ls

-a: enumera todos los archivos, incluido el archivo oculto que comienza con ‘.’

–color: lista de colores (cuando) [=always/never/auto]

-d: list directories – con ‘* /’

-F: agregue un carácter de * / => @ | a las entrañas

-i: enumerar el número de índice de inodo del archivo

-l: lista con formato largo – mostrar permisos

-la: lista de formato largo incluyendo archivos ocultos

-lh: lista formato largo con tamaño de archivo legible

-s: lista de tamaño de archivo

-ls: lista con formato largo con tamaño de archivo

-r: lista en orden inverso

-R: enumerar el árbol de directorio recursivamente

-S: ordenar por tamaño de archivo

-t: ordenar por hora y fecha

-X: ordenar por nombre de la extensión

-F, –classify: Indicador de adición (uno de * / => @ | ) a las entradas.

–file-type: Similar a –classify , excepto que no se agrega ‘ * ‘

–format = palabra Formatos de acuerdo con lo siguiente: a través de -x , comas -m , horizontal -x , largo -l , una sola columna -1 , detallado -l , vertical -C.

–full-time: Como -l.

-g: Como -l , pero no lista el propietario del archivo / directorio.

–group-directories-first: Agrupa los directorios antes de los archivos. Se puede aumentar con una opción –sort , pero cualquier uso de –sort = none (- U ) deshabilita la agrupación.

Ejemplos de uso

Lista de directorio ~/docs/ con ruta relativa : ls -la ~/docs/

La lista del directorio  /usr/ con ruta absoluta. ls /usr/

Listar el directorio raíz: ls /

Lista de directorio principal: ls ..

Indique el directorio de inicio del usuario (p. Ej .: / home / user): ls ~

Listar solo archivos de texto con comodín: ls *.txt

Enviar la respuesta de ls a un archivo de salida: ls -R ~/*.txt > out.txt

Solo directorios de lista:  ls -d * /

Modelo de clases del dominio

 MODELO DE DOMINIO

Un modelo de dominio es una representación de las clases conceptuales del mundo real, no de componentes software. No se trata de un conjunto de diagramas que describen clases software, u objetos software con responsabilidades.

• Su utilidad radica en ser una forma de “inspiración” para el diseño de los objetos software.
• Es entrada para muchos de los artefactos que se construyen en un proceso software.
• Un modelo de dominio muestra las clases conceptuales significativas en un dominio del problema.
• Se centra en las abstracciones relevantes, vocabulario del dominio e información del dominio.
• Es el artefacto clave del análisis orientado a objetos.
• En UML se utilizan los diagramas de clases para representar los modelos de dominio.

GUÍAS PARA HACER UN MODELO DE DOMINIO

• Listar las clases conceptuales candidatas relacionadas con los requisitos actuales en estudio.
• Representar las clases en un modelo de dominio.
• Añadir las asociaciones necesarias para registrar las relaciones que hay que mantener en memoria.
• Añadir los atributos necesarios para satisfacer los requisitos de información.

IDENTIFICACIÓN DE CLASES CONCEPTUALES

• El modelo de dominio muestra las clases conceptuales o vocabulario del dominio.
• Informalmente una clase conceptual es una idea, cosa u objeto.
• Formalmente, una clase conceptual puede considerarse en términos de su símbolo, intensión y extensión (Martin y Odell, 1995).
• Símbolo: palabras o imágenes que representan una clase conceptual.
• Intensión: la definición de una clase conceptual.
• Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual.

• Objetivo crear un modelo de dominio de clases conceptuales significativas del dominio de interés
• Se van añadiendo clases al modelo del dominio a medida que se revisan los escenarios identificados en los casos de uso
• Es mejor especificar en exceso un modelo de dominio con muchas clases conceptuales de grano fino que especificar por defecto (Larman, 2002)
• El modelo no es mejor por tener pocas clases conceptuales
• Es normal obviar clases conceptuales durante la identificación inicial para descubrirlas más tarde (incluso en diseño) al considerar atributos y asociaciones
• No se deben excluir clases conceptuales porque los requisitos no indican necesidad obvia de registrar información sobre ella o porque la clase conceptual no tenga atributos
• Estrategias para identificar clases conceptuales
• Utilizar una lista de categorías de clases conceptuales
• Identificar frases nominales
• Patrones de análisis (Fowler, 1996; Hay, 1996])
• Un patrón de análisis es un modelo de dominio parcial y existente que ha sido creado por expertos

Método: Lista de categorías (Shlaer y Mellor, 1988; Larman, 2002)

Objetos tangibles o físicos: Avión, asiento, billete, equipaje, tarjeta de embarque…

Roles: papeles desempeñados por personas u organizaciones: Piloto, agente de ventas, pasajero…

Incidentes: representan la ocurrencia de un evento, algo que sucede en un momento determinado: Cancelación de vuelo, vuelo, aterrizaje, colisión…

Interacciones: transacciones o contratos que se dan entre dos o más objetos del modelo: Reserva, venta de billete, pago…

Líneas de las transacciones: Línea de venta…

Especificaciones: propias de aplicaciones de inventario o fabricación. Relacionados con los estándares o definiciones de elementos. Descripciones: Descripción del vuelo…

Organizaciones: Departamento de ventas, compañía aérea…

Lugares: Tienda…

Contenedores: Avión, tienda, lata…

Cosas contenidas: Artículo, pasajero

Conceptos abstractos: Ansia, claustrofobia…

Otros sistemas informáticos externos al sistema: Control de tráfico aéreo, sistema de autorización de pago a crédito…

Método (Coad y Yourdon, 1990). 

• En primer lugar se buscan candidatos entre las siguientes categorías
• Otros sistemas: Sistemas externos que interaccionan con el sistema en estudio: Control de tráfico aéreo
• Dispositivos: Dispositivos físicos que interaccionan con el sistema en estudio intercambiando información control y datos. No incluir componentes de ordenador (discos, pantallas...): Sensor
• Hechos (eventos a registrar): Equivalente a los incidentes de (Shlaer y Mellor, 1988)
• Roles
• Localizaciones: ¿De qué localizaciones físicas, oficinas o sitios se ha de tener conocimiento?
• Unidades organizativas: Compañía aérea
• De los candidatos se incluyen en el modelo aquéllas que cumplan una o más de las siguientes propiedades
• Guardar información: Se necesita guardar información acerca de las clases potenciales
• Usuario del sistema
• Necesidad de servicio: Incorporan un conjunto de operaciones que pueden proveer servicios a otras clases
• Partida: Proporciona información que caracteriza el estado de un juego – puntuación de los jugadores, tiempo de pensar…
• Atributos múltiples: La clase tiene más de un atributo
• Balance: Representa una cantidad, esto es, balance como atributo de Cuenta
• Atributos comunes: Todas las instancias del “nombre” comparten los mismos atributos
• Cliente (nombre, dirección, teléfono...)
• Operaciones comunes: Todas las operaciones definidas para el “nombre” se aplican al resto de las instancias del nombre
• Cliente [getName()]
• Requisitos esenciales: Entidades externas conocidas por el sistema y que producen o consumen información

IDENTIFICACIÓN DE ASOCIACIONES

Se deben de incluir las siguientes asociaciones en un modelo del dominio (Larman, 2002)

• Asociaciones de las que es necesario conservar el conocimiento de la relación durante algún tiempo (asociaciones necesito-conocer)
• Asociaciones derivadas de la lista de categorías comunes de asociaciones

Se deben eliminar

• Las relaciones no permanentes
• Aquéllas que sean irrelevantes para la especificación
• Orientadas a la implementación
• Las que pueden derivarse a partir de otras asociaciones

Se deben definir nombres de asociación, roles, multiplicidad

Guía para las asociaciones (Larman, 2002)

• Centrarse en las asociaciones necesito-conocer
• Es más importante identificar clases conceptuales que identificar asociaciones
• Demasiadas asociaciones tienden a confundir un modelo de dominio en lugar de aclararlo. Su descubrimiento puede llevar tiempo, con beneficio marginal
• Evitar mostrar asociaciones redundantes o derivadas

Lista de asociaciones comunes (Larman, 2002)

• A es una parte física de B => Ala – Avión
• A es una parte lógica de B => EtapaVuelo – RutaVuelo
• A está contenido físicamente en B => Pasajero – Avión
• A está contenido lógicamente en B => Vuelo – PlanificaciónVuelo
• A es una descripción de B => DescripciónDelVuelo – Vuelo
• A es una línea de una transacción o informe de B => TrabajoMantenimiento – RegistroDeMantenimiento
• A se conoce/registra/recoge/informa/captura en B => Reserva – ListadePasajeros
• A es miembro de B => Piloto – CompañíaAérea
• A es una unidad organizativa de B => Mantenimiento – CompañíaAérea
• A utiliza o gestiona a B => Piloto – Avión
• A se comunica con B => AgenteDeReservas – Pasajero
• A está relacionado con una transacción B => Pasajero – Billete
• A es una transacción relacionada con otra transacción B => Reserva – Cancelación
• A está al lado de B => Ciudad – Ciudad
• A es propiedad de B => Avión – CompañíaAérea
• A es un evento relacionado con B => Salida – Vuelo

IDENTIFICACIÓN DE ATRIBUTOS

Son las propiedades relevantes de los objetos individuales.

Antes de identificar los atributos es necesario identificar las asociaciones

    • Relacionar las clases conceptuales con asociaciones no con atributos

La mayoría de los atributos simples son los que conocen como tipos de datos primitivos

• El tipo de un atributo no debería ser un concepto de dominio complejo
• Los atributos deben ser, generalmente, tipos de datos
• Un tipo de dato para UML implica un conjunto de valores para los cuales no es significativa una identidad única (en el contexto del modelo o sistema en el que se está trabajando) (Rumbaugh et al., 1999)

Se deberían incluir en un modelo de dominio aquellos atributos para los que los requisitos sugieren o implican una necesidad de registrar la información (Larman, 2002)

En caso de duda es mejor definir algo como una clase conceptual en lugar de como un atributo

Se debe representar lo que podría considerarse, inicialmente, como un tipo de dato como una clase no primitiva si (Larman, 2002)

• Está compuesta de secciones separadas
• Habitualmente hay operaciones asociadas con él, como análisis sintáctico o validación
• Tiene otros atributos
• Es una cantidad con una unidad
• Es una abstracción de uno o más tipos con alguna de estas cualidades

IDENTIFICACIÓN DE RELACIONES DE GENERALIZACIÓN

La definición de una superclase conceptual es más general y abarca más que la definición de una subclase

Todos los miembros del conjunto de una subclase conceptual son miembros del conjunto de su superclase

Se tiene que tener la conformidad con la definición de la superclase. Regla del 100% (Larman, 2002)

• El 100% de la definición de la superclase conceptual se debe poder aplicar a la subclase. La subclase debe ajustarse al 100% de los atributos y asociaciones de la superclase

Una subclase debe ser miembro del conjunto de la superclase. Regla Es-un (Larman, 2002)

• Todos los miembros del conjunto de una subclase deben ser miembros del conjunto de su superclase

Una subclase conceptual correcta debe cumplir (Larman, 2002)

• La regla del 100% (conformidad en la definición)
• La regla Es-un (conformidad con la pertenencia al conjunto)

Razones para especializar una clase conceptual en subclases

• Una partición de clases conceptuales es una división de las clases conceptuales en subclases disjuntas (Martin y Odell, 1995)
• Se debería crear una subclase conceptual de una superclase cuando (Larman, 2002)
• La subclase tiene atributos adicionales de interés
• La subclase tiene asociaciones adicionales de interés
• El concepto de la subclase funciona, se maneja, reacciona, o se manipula de manera diferente a la superclase o a otras subclases, de alguna manera que es interesante
• El concepto de la subclase representa alguna cosa animada que se comporta de manera diferente a la superclase o a otras subclases, de alguna forma que es interesante

Razones para definir una superclase conceptual

• Se aconseja generalizar una superclase común cuando se identifican elementos comunes entre las subclases potenciales
• Se debería crear una superclase conceptual en una relación de generalización de subclases cuando (Larman, 2002)
• Las subclases potenciales representen variaciones de un concepto similar 
• Las subclases se ajustan a las reglas del 100% y Es-un
• Todas las subclases tienen el mismo atributo que se puede factorizar y expresar en la superclase 
• Todas las subclases tienen la misma asociación que se puede factorizar y relacionar con la superclase

Clases conceptuales abstractas

• Es útil identificar las clases abstractas en el modelo del dominio porque esto restringe las clases que pueden tener instancias concretas
• Se clarifican las reglas del dominio del problema
• Si cada miembro de una clase A puede ser también miembro de una subclase, entonces A es una clase conceptual abstracta

Pueden existir instancias de A que no sean

instancias de B, C o D. Entonces A no es una

clase conceptual abstracta

A es una clase conceptual abstracta. Una

instancia de A debe conformar con una de

sus subclases, B, C o D

Modelado de los cambios de estado

• No se debe modelar el estado de un concepto X como subclases de X, sino que se debe seguir una de estas dos estrategias (Larman, 2002)

• Definir una jerarquía de estados y asociar los estados con X

• Ignorar la representación de los estados de un concepto en el modelo de dominio; en lugar de esto representar los estados en diagramas de estados

Modelo con histórico de estados (pero en el que se sabe que nunca se pasará dos veces por el mismo estado)

Modelo con histórico de estados (pero en el que no se puede garantizar que nunca se pasará dos veces por el mismo estado)

No se debe utilizar la relación de generalización para modelar situaciones estructurales que son susceptibles de cambiar con el paso del tiempo

• La relación de generalización es estática
• Es muy frecuente que los modelos tengan que reflejar situaciones estructurales que cambian con el paso del tiempo
• Se debe valorar modelar mediante roles

Un turno de trabajo en un restaurante está compuesto por un jefe de sala, cuatro camareros, un jefe de cocina, dos cocineros y dos ayudantes de cocina

Un turno de trabajo en un restaurante está compuesto por un jefe de sala, cuatro camareros, un jefe de cocina, dos cocineros y dos ayudantes de cocina

IDENTIFICACIÓN DE RELACIONES TODO-PARTE

El patrón todo-parte se da en tres tipos de configuración

• Ensamblaje y sus partes
• Suele corresponder a un producto real y sus partes constituyentes
• Ordenador (placa base, disco...)
• Contenedor y sus contenidos
• Variante del anterior. Más relacionado con agrupaciones “lógicas”
• Oficina (mesas, teléfonos, estanterías...)
• Grupo y sus miembros
• Agrupación de intereses
• Asociación (ACM) y sus miembros (asociados)

Una relación todo-parte puede utilizarse cuando (Larman, 2002)

• El tiempo de vida de la parte está ligado al tiempo de vida del todo
• Existe una dependencia de creación-eliminación de la parte en el todo
• Existe un ensamblaje obvio todo-parte físico o lógico
• Alguna de propiedad del compuesto se propaga a las partes, como la ubicación
• Las operaciones que se aplican sobre el compuesto se propagan a las partes, como la destrucción, movimiento o grabación

Dos tipos de relación

• Agregación
• Composición

Agregación vs. Composición

Agregación

• Un objeto agregado es un objeto construido a partir de otros objetos
• El agregado es mayor que la suma de sus partes
• Todas las interacciones realizadas con el conjunto de los objetos agregados se realizan a través de la interfaz del objeto agregado
• Los objetos componentes están ocultos o encapsulados dentro del agregado

• Multiplicidad en las dos partes de la relación
• Las partes pueden existir incluso después de que el agregado sea “desmontado” o destruido
• Las partes pueden cambiar de un agregado a otro

Composición

• La composición es una forma fuerte de agregación
• El ciclo de vida de las partes depende del ciclo de vida del agregado
• Las partes no existen fuera de su participación en el agregado
• La pertenencia fuerte implica objetos físicos que se unen para formar el compuesto

• La multiplicidad en el “extremo” del compuesto es 1 o 0..1
• Multiplicidad en el “extremo” de las partes del compuesto
• Si el agregado se “desmonta” o se destruye las partes no tienen existencia propia
• Las partes no se pueden mover de una composición a otra

Cursos adaptables. Se pueden crear combinando lecciones y ejercicios ya existentes creando una tabla de contenidos nueva

• La tabla de contenidos es única para cada curso
• La lección aparece en la tabla de contenidos para cada curso que la usa
• Las lecciones se desarrollan para un curso pero se pueden usar para construir otros cursos
• Los ejercicios se desarrollan inicialmente para un curso pero pueden ser utilizados con otras lecciones para otros cursos

• Cursos fijos. Se crean y se entregan. Para crear un nuevo curso todo el material se crea desde de cero
• La tabla de contenidos es única para cada curso
• La tabla de contenidos hace referencia a cada lección del curso. Cada lección solamente aparece en la tabla de contenidos del curso para el que fue desarrollada
• Las lecciones se utilizan únicamente en el curso para el que fueron desarrolladas
• Los ejercicios se utilizan únicamente en las lecciones para las que fueron desarrollados

Identificar y representar las relaciones todo-parte no es excesivamente importante en el modelo de dominio

Descubrir y mostrar relaciones todo-parte si se obtiene alguno de los siguientes beneficios (Larman, 2002])

• Aclara las restricciones de dominio en cuanto a la existencia que se desea de la parte independiente del todo 
• En la composición, la parte no podría existir fuera del tiempo de vida del todo 
• Ayuda a la identificación de un creador (el compuesto) 
• Las operaciones que se aplican al todo frecuentemente se propagan a las partes

RUP - Proceso de Desarrollo Unificado

Proceso del Desarrollo Unificado

Descripción

El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retro-alimentación, garantizando el cumplimiento de ciertos estándares de calidad.El proceso de desarrollo constituye un marco metodológico que define en términos de metas estratégicas, objetivos, actividades y artefactos (documentación) requerido en cada fase de desarrollo.Esto permite enfocar esfuerzo de los recursos humanos en términos de habilidades, competencias y capacidades a asumir roles específicos con responsabilidades bien definidas.

Estructura del ciclo de vida del proceso de desarrollo unificado:

Fases

Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición.

Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de

disciplinas o flujos de trabajos.

Disciplinas

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son:

Requerimientos, Análisis, Diseño, Codificación, y Prueba.

El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visión tradicional en cascada.

Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos.Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso,modelo de diseño, modelo de implementación, y modelo de prueba.

Características

• Es iterativo e incremental
• Dirigido por los casos de uso
• Centrado en la arquitectura
• Enfocado en los riesgos

Sprint y su relacion con el Scrum

En si la palabra Sprint se refiere a una carrera a máxima velocidad. En Scrum se trata de un pequeño bloque de tiempo, de cuatro semanas o menos, durante el cual se crea un incremento de producto “terminado” utilizable y potencialmente entregable. Cada nuevo Sprint comienza inmediatamente después de la finalización del anterior y es el bloque central del Scrum.

El Sprint es un contenedor de los demás eventos y actividades de Scrum: Planificación del Sprint, Scrums Diarios (Dailys), trabajo de desarrollo, Revisión del Sprint (Review) y la Retrospectiva del Sprint.

Un Sprint no busca velocidad, sino que se enfoca en el trabajo colaborativo y conectado durante un período de tiempo acotado. 

Revisemos ahora las características de un Sprint:

1. Corta duración

Mientras menor es la duración de cada Sprint existe mayor facilidad para realizar la inspección y adaptación del desarrollo. Cuando el horizonte de un Sprint es demasiado grande la definición de lo que se está construyendo podría cambiar, la complejidad podría incrementarse y el riesgo podría aumentar. Al ser de corta duración generan los siguientes beneficios:

• Transparencia.
• Motivación.
• Acota el error.
• Fácil planificación.
• Mejora el Retorno de la Inversión (ROI).

2. Timeboxed

El Sprint posee una duración predefinida. Esto corresponde a una técnica de gestión del tiempo que ayuda a organizar, focalizar y hacer eficiente el desempeño.

Tener un tiempo predefinido y acotado obliga a desagregar o atomizar el desarrollo en pequeños ítems que deben caber dentro del timebox.

3. Inicia al finalizar el Sprint anterior

Un Sprint siempre se inicia inmediatamente después de finalizado el Sprint anterior. No existe tiempo intermedio entre uno y otro, por lo tanto, no pueden existir eventos, tareas ni actividades que se realicen entre el término de un Sprint y el inicio del siguiente.

4. Objetivo no modificable

Durante la reunión de Sprint Planning se negocia y define un objetivo para el Sprint (Sprint Goal). Una regla primordial de Scrum es que una vez que comienza la ejecución del Sprint el objetivo debe permanecer inalterable.

5. Incremento de producto entregable

Cada Sprint debe tener como resultado incrementar el producto en una pequeña funcionalidad o aspecto que esté completamente listo, es decir, que cumpla la definición de “Done” para pasar a producción.

Cada Sprint debe considerar todo el proceso de desarrollo, pruebas e integración, ya que el resultado del Sprint debe incrementar el producto en forma real y tangible, lo que se logra solo si el desarrollo está plenamente integrado.

Conozcamos los 2 conceptos claves en el mundo del Scrum: “Ready” y “Done”:

-Definición de Ready: Corresponde al estado y a la cantidad de detalles que deben tener los ítems del Product Backlog antes de que puedan ser ingresados a la reunión de Sprint Planning.

-Definición de Done: Es un convenio entre el Equipo de Desarrollo y el Product Owner en el que  acuerdan qué implica un ítem Done o finalizado. En Scrum cada resultado de un Sprint debiese ser un incremento de producto potencialmente entregable.

Auditoría de Sistemas - Introducción

Profesora: Mg. Bibiana Anselmo
Magister de informática y
bibiana.anselmo.usal@gmail.com

Materia cuatrimestral, viernes de 19hs a

1 parcial
1 trabajo practico grupal -> 4 personas
        Se compone de dos partes: Carta/Informe auditor - Presentación a la gerencia.
                                                    Presentación oral.

No es promocionarle.

Auditoria

La auditoria es una función independiente de control, ya que no depende de ningún área, del funcionamiento de un sistema.
Los auditores verifican que el sistema hace lo que dice que tiene que hacer, para lo que fue diseñado.

El Objeto de la auditoria en nuestro caso es el Sistema, "de Sistemas".
El Sujeto, el auditor, puede ser externo o interno, los auditores pueden ser externos pero las empresas pueden tener auditores internos.

La principal fuente conocimiento del auditor es el flujo de transacciones, las entradas y las salidas de la información. Para el auditor el proceso en si es una caja negra.

Proceso de auditoria

Lo primero que se establece en una auditoria son los objetivos de esta. En estos se define que procesos y sistemas se van a revisar.
Para auditar un negocio primero lo tengo que entender, recién entendiéndolo voy a poder establecer la estrategia. Se establece que puede salir mal en el negocio, se buscan los riesgos, y se plantean las estrategias.
Luego se ejecutan los procedimientos planificados.
Finalizar la auditoria, cerrando los procedimientos y enviando el informe final con las observaciones.

"El riesgo se reduce, se mitiga, pero no desaparece."

Técnicas de auditoria

En tiempos primigenios la auditoria se realizaba en papel y lápiz, eso ya casi no sucede.
Pruebas sobre herramientas, donde cada vez se usa mas el test off one, donde se dejo de probar 25 veces para probar una sola vez con sistemas automáticos.

CAATs o ASL son programas para auditoría. ASL es un excel en la cual los datos no se podían modificar. Queda una copia impoluta de los datos y un registro de quien y cuando hizo que modificación en el archivo.

Metodología Orientada a objetos

Metodología Orientada a objetos

No solo nos referimos a la programación orientada a objetos si no que se la metodología incluye el Análisis Orientado a Objetos, el Diseño Orientado a objetos y la Programación Orientada a objetos.

Programación Orientada a Objetos, un paradigma de programación que permite desarrollar aplicaciones complejas manteniendo un código más claro y manejable que otros paradigmas anteriores.

La programación Orientada a objetos se define como un paradigma de la programación, una manera de programar específica, donde se organiza el código en unidades denominadas clases, de las cuales se crean objetos que se relacionan entre sí para conseguir los objetivos de las aplicaciones.

La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real que otros tipos de programación.

Para la implementacion de esta metodología vamos a requerir los siguiente mecanismos: 

• Objetos: encapsulamiento de datos y métodos. Los objetos son ejemplares de una clase cualquiera. Cuando creamos un ejemplar tenemos que especificar la clase a partir de la cual se creará. Esta acción de crear un objeto a partir de una clase se llama instanciar (que viene de una mala traducción de la palabra instace que en inglés significa ejemplar). 
• Clases: declaraciones de objetos, también se podrían definir como abstracciones de objetos. Esto quiere decir que la definición de un objeto es la clase. Cuando programamos un objeto y definimos sus características y funcionalidades en realidad lo que estamos haciendo es programar una clase. 
• Mensajes: comunicación (colaboración) entre objetos. Un mensaje en un objeto es la acción de efectuar una llamada a un método.
• Métodos: funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos métodos. Los métodos son como funciones que están asociadas a un objeto.

Los Objetos están compuestos principalmente por:

• Identidad: dato que lo hace único al objeto.
• Estado: propiedades y atributos, datos y valores del objeto en un momento dado.
• Comportamiento: métodos y funciones de objetos (que es lo que hace el objeto).

Visibilidad de atributos y métodos (public, protected y private).

En una clase podemos definir nuestros atributos y métodos como públicos, protegidos o privados (public, protected o private) en función de la visibilidad que queremos que tengan en el resto del código. 

Diferencias entre public, protected y private:

Public: podemos acceder a las propiedades y métodos desde cualquier lugar, desde la clase actual, clases que heredan de la clase actual y desde otras clases.

Protected: se puede acceder al atributo o método desde la clase que lo define y desde cualquier otra que herede de esta clase.

Private: los atributos o métodos solo son accesibles desde la clase que los define.

Características de la POO

La abstracción es la generaliacion de los objetos que como resultado nos define las clases. Consiste en aislar un elemento de su contexto o del resto de los elementos que lo acompañan. En programación, el término se refiere al énfasis en el "¿qué hace?" 

La encapsulación es un mecanismo que consiste en organizar datos y métodos de una estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el acceso a datos por cualquier otro medio distinto a los especificados. Por lo tanto, la encapsulación garantiza la integridad de los datos que contiene un objeto.

La implementacion del encapsulamiento se realiza declarando los datos de la clase como privados para que no se pueda acceder a ellos y los métodos de retorno de información y de trabajo como públicos.

La herencia sirve para crear objetos que incorporen propiedades y métodos de otros objetos. Así podremos construir unos objetos a partir de otros sin tener que reescribirlo todo. Responde a la pregunta "es un ...".

Siempre voy a tener una estructura jerárquica donde voy a tener una clase padre/base y una o mas clases derivadas.

El polimorfismo sirve para que no tengamos que preocuparnos sobre lo que estamos trabajando, y abstraernos para definir un código que sea compatible con objetos de varios tipos.

El polimorfismo puede ser estático o dinámico.

Se denomina "modularidad" a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos.

Principio de ocultación. Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una "interfaz" a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas; solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no puedan cambiar el estado interno de un objeto de manera inesperada, 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 abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.


Interacción entre objetos (Asociación)

La asociación se podría definir como el momento en que dos objetos se unen para trabajar juntos y así, alcanzar una meta.

Agregación
La agregación es un tipo de asociación que indica que una clase es parte de otra clase. Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de agregación o de varias asociaciones de agregación distintas). Un punto a tomar muy en cuenta es que ambos objetos son independientes entre sí, la destrucción del compuesto no conlleva la destrucción de los componentes.
Para validar la asociación, la frase “Usa un”, debe tener sentido:

• El ingeniero usa una computadora
• El cliente usa tarjeta de crédito.

En la agregación se crea el objeto antes de agregarlo (este ya debe existir).

Composición
Composición es una forma fuerte de composición donde la vida de la clase contenida debe coincidir con la vida de la clase contenedor. Los componentes constituyen una parte del objeto compuesto. De esta forma, los componentes no pueden ser compartidos por varios objetos compuestos. La supresión del objeto compuesto conlleva la supresión de los componentes.
En esta situación, la frase “Tiene un”, debe tener sentido:

• El auto tiene llantas
• La portátil tiene un teclado.

La creación del objeto se realiza en el objeto principal.