Análisis orientado a objetos

Manteniendo la línea de las dos publicaciones anteriores, hoy os voy a hacer otra incisión a conceptos relacionados con Ingeniería del Software. Concretamente, voy a hacer una pequeña introducción al análisis orientado a objetos.

Como es costumbre, lo primero que haré será definir unos primeros conceptos básicos. Esta vez, sobre Orientación a Objeto (OO) ...

Características básicas de OO

• Abstracción: denota las características esenciales de un objeto que permiten diferenciarlo de otros tipos de objetos, definiendo así los límites conceptuales desde el punto de vista del usuario.
• Modularidad: es la propiedad que permite descomponer un sistema complejo en partes más manejables e independientes.
• Encapsulamiento: permite ocultar la implementación. Complementa a la abstracción, ya que la abstracción se preocupa de la visión externa de un objeto y el encapsulamiento evita que los clientes vean los detalles internos.
• Jerarquía: se ordenan las abstracciones jerárquicamente. Se definen objetos generales y subcategorias de éstos. Generalización (herencia) y Agregación/Composición (ser parte o estar compuesto de algo).

Conceptos Básicos de OO

1. Objeto: entidad que existe en el mundo real y que tienen un comportamiento.
2. Clase de Objetos: describe un conjunto de objetos con las mismas propiedades (atributos), comportamiento (operaciones), relaciones entre ellos y semántica.Implementa el principio de Abstracción y sirve como patrón para crear objetos.
3. Atributos: son las propiedades compartidas por los objetos de una clase y tienen valor dependiendo de la instancia del objeto. Pueden ser básicos o derivados (de datos que aparecen de otra información)
4. Operaciones: funciones que se pueden aplicar a objetos de una clase. Se deben reconocer los argumentos y los resultados.
• Métodos. implementación de una operación dentro de una clase.
• Polimorfismo. permite que una misma operación se pueda aplicar en diferentes clases, por lo que su implementación dependerá de cada clase.
5. Relaciones:
• Asociaciones. definen la manera de conectar los objetos de diferentes clases. Podemos ir de un objeto a otro siguiendo la relación.
• Agregación. modela una relación “todo-parte”.
• Composición. es un tipo de agregación, con la diferencia de que la parte no existe sin el todo.
• Generalización. representa una relación “ser tipo de”. Define jerarquía de abstracciones.
• Herencia. permite que las estructuras de datos y las operaciones de una clase sean accesibles para sus subclases.
  

- Multiplicidad: define cuantos objetos participan en la relación. “Cuantos de estos objetos se relacionan con tantos de estos”

- Navegación: las asociaciones y las agregaciones son bidireccionales por defecto, pero hay veces que necesitamos restringir el sentido y utilizaremos flechas para indicar la dirección de navegación.


UML:Unified Modeling Language
Es un lenguaje visual de modelado orientado a objetos. Nos ayuda para entender el sistema ya que especifica las funciones que debe tener, y nos muestra los modelos del sistema para poder tener una perspectiva global sobre él.

Los lenguajes de modelado empiezan a surgir entre la década de los '70 y finales de los '80, y llegan a crearse varios tipos diferentes -lo que crea insatisfacción por parte de los usuarios-. De todos los existentes se escogen tres y en 1994 comienza la unificación entre ellos: Booch, OMT i OOSE. La primera versión UML (1.1) aprobada para su estandarización no aparece hasta 1997.
La aparición del UML tenía como objetivos, principalmente, el modelado de sistemas sin importar el tamaño de estos, desde el principio hasta el final, de una manera sencilla y capaz de utilizarse tanto por personas como por máquinas

Definición UML. Es un lenguaje para visualizar, especificar, construir, documentar los elementos de un sistema complejo, desde una visión orientada a objetos. No se trata de un proceso, no nos indica cómo hacer las cosas, simplemente es una notación (escrita, reglada y gráfica) con una semántica bien definida.
Se necesitan múltiples modelos para cubrir las diferentes vistas de la arquitectura del sistema.

Características

• especifica todas las decisiones de análisis, diseño e implementación construyendo modelos precisos, claros y completos.
• puede utilizarse en cualquier lenguaje de programación. Podemos para del diseño UML al código gracias a la ingeniería directa , y viceversa mediante la ingeniería inversa.
• permite documentar todos los elementos de un proceso de desarrollo.

Análisis de requerimientos (parte 2)

TÉCNICAS DE DETERMINACIÓN DE REQUERIMIENTOS

- Conversaciones, entrevistas, reuniones con el cliente. Podemos encontrarnos con los varios problemas:

• con la existencia de diferencias entre los usuarios, obtenemos puntos de vista muy diversos. La idea es la realización de todas las entrevistas posibles para poder contemplar todos esos puntos y analizar mejor.
• los usuarios no suelen tener experiencia o conocimiento del sistema.
• hacernos una idea del sistema, definiendo solo esta técnica, es complicado. Tendremos que utilizar técnicas alternativas para conseguir más información.

FASES ENTREVISTAS

1. Preparación. Determinamos las preguntas que van a hacerse (obtendremos un estudio sobre el dominio del problema), seleccionamos a un subconjunto de personas para obtener el mayor número de información posible, determinamos el objetivo y contenido de la misma y las planificamos.
   
2. Realización. Consta de 3 partes. En la apertura se deja claro al usuario cuál es el objetivo de la entrevista y se aclaran conceptos o notación específica que se vaya a utilizar durante la misma. En el desarrollo, máximo de 2 horas, hemos de mantener el control y dejar que el usuario se explique; hay que evitar monólogos por parte de los entrevistadores. Al final se debe hacer una recapitulación de la información dada por el usuario.
3. Análisis de las entrevistas, extraemos la información recogida por la mi

- Obtener requerimientos a partir de un Sistema de Información (sinónimo de sistema informático) desarrollado. Podemos utilizar esta técnica como complemento de la anterior ya que puede darnos mucha información más útil (en algunos casos que los usuarios no colaboran con datos concretos). Eso si, su problemática radica en sistemas complejos y en sistemas que nunca han existido.

- Obtener los requerimientos a partir del Sistema de Información mismo. Es necesario que los analistas conozcan lo que existe ya en la empresa donde vamos a poner el nuevo sistema. El problema de esta técnica es que tiene un coste elevado ya que se añade a esta fase un análisis de todo lo que ya hay y eso necesita tiempo y más personal que lo haga.

- Construcción de un prototipo. Definimos un prototipo con las características generales del sistema y vamos conociendo los requerimientos en función de las versiones. Es una técnica muy costosa.

- Casos de uso. Se identifican los requerimientos funcionales y no funcionales y se relacionan entre ellos. Nos preguntamos cuales son las funciones del sistema por cada actor (persona relacionada con el sistema).


¿QUÉ SE HACE EN EL ANÁLISIS DE REQUERIMIENTOS?

1. Comprensión del problema mediante la comprensión (valga la redundancia) del software dentro del contexto y la evaluación y síntesis del propio problema (definición de flujos, estructura y contenido de la información, funciones y entendimiento del comportamiento)
2. Modelización del sistema
3. Especificación del sistema mediante una representación formal y comprovación de que lo que ha recogido el analista es lo que realmente necesita el cliente.

Problemática
- Uno de los primeros conflictos con los que nos encontramos es en el momento de decidir que personas podrán darnos la información que necesitamos para plantear las necesidades del cliente. Nos encontramos con que un alto porcentaje de la gente que preguntamos no nos la da realmente.
- Es probable que para una misma función nos encontremos con diferente información de diferentes personas, por lo que se convierte en información inconsistente.
- Podemos encontrar problemas en el momento de integrar nuestro nuevo sistema por culpa del funcionamiento y rendimiento de otros elementos del sistema. Por ejemplo, puedo encontrarme con errores en el momento que decido conectarme a otro software para obtener datos.
- La percepción de los objetivos puede cambiar con el paso del tiempo.
- A medida que crece el tamaño del problema, crece la complejidad del análisis.
- El cliente no suele valorar la etapa de análisis.

Métodos de modelado
Cada método de análisis tiene una notación y un punto de vista propio, pero siempre se tiene que cumplir 3 reglas:

1. Partición. un sistema complejo solo puede entenderse si se divide en partes más pequeñas que se relacionan entre ellas; esto nos permite ver el problema en pequeñas partes y luego, de su relación, llegar a tener una visión general de él.
2. Abstracción. nos debe permitir ver el sistema en términos generales, sin tener en cuenta cómo generamos entradas y salidas del sistema.
3. Proyección. permite definir el problema teniendo en cuenta los diferentes puntos de vista.

Especificación de requerimientos
Es el resultado del análisis. Se trata de un documento que sirve de contrato entre el desarrollador y el cliente, y de base de trabajo para el diseñador.

- Explica qué hace el sistema, y no el cómo lo hace.
- Debe ser un documento comprensible para cualquier persona. Se precisa la explicación de los tecnicismos en el caso de que los haya.
- Los conceptos a explicar deben estar claros.
- La información debe estar completa, debe recoger todos los requerimientos y a su vez, estos deben de ser verificados por el cliente.
- No debe haber requisitos contradictorios.
- Debe ser un documento fácilmente modificable.
- Debe tener un índice.
- Deber poder ser usable durante el diseño y la implementación, y el mantenimiento del sistema.

- Un estándar de este documentos es el de ANSI/IEEE.

- Posteriormente el documento debe ser revisado y validado en dos niveles: macroscópico (especificación completa, consistente y precisa) y detallado (precisar temas concretos).

Análisis de requerimientos (parte 1)

Aprovechando que estoy estudiando teórico y soy una negada para retener las cosas como si fuera un loro, he querido redactar un poco sobre análisis de requerimientos para la asignatura de Ingenieria del Software. Creo que es la única manera de aprenderme conceptos tan teóricos.

El post tendrá dos partes: la primera es la que se muestra a continuación, introduciendo unos cuantos conceptos básicos y explicando en que consiste el análisis del sistema y que cosas hay que tener en cuenta; la segunda la subiré más tarde, o mañana, y englobará las técnicas de determinación de requerimientos, su posterior análisis y cómo han de especificarse.

Para empezar, vamos a definir unos cuantos conceptos...

Un sistema informático es un conjunto de elementos organizados para realizar algún método, procedimiento o control mediante el procesamiento de información. Dentro de un sistema informático no sólo encontramos software o hardware, sino que también diferentes roles de personas, bases de datos, documentos o procedimientos.

Un requisito, propiamente dicho, es la condición o capacidad necesitada por el usuario para poder llegar a solucionar un problema (o cumplir unos objetivos). En otras palabras, es lo que tiene que llegar a hacer el sistema.

La solución a un problema, puede resolverse de 4 maneras: manualmente, mediante software, mediante hardware o mediante la combinación de las tres.
Dicha solución puede ser simple (mediante un software simple) o compuesta (mediante un sistema más complejo, automatizando todas las acciones). En el caso del sistema compuesto es necesario diseñar el sistema global antes de diseñar el software que se integre.

La ingeniería de sistemas informáticos es la actividad que se encarga de resolver estos problemas. Para ello, es necesario que el cliente que nos pide la integración participe en el desarrollo (en general) del producto aportando los objetivos y restricciones que debe tener el sistema. El ingeniero es quién desarrolla la solución; en un primer momento será él el que analice el sistema delimitando el ámbito de funcionamiento, el rendimiento y las funciones. Con esta información tendrá que determinar una serie de soluciones entre las que escogerá la mejor teniendo en cuenta, entre otras cosas, la existencia de un producto en el mercado que resuelva sus necesidades (“es el caso de la necesidad de tener una hoja de cálculo, no la desarrollaremos porque ya existe”), el coste que podría suponer, el tipo de tecnología o las necesidades reales a cubrir.

ETAPAS DEL ANÁLISIS DEL SISTEMA

1. Identificar las necesidades del cliente. Podremos determinar los objetivos a conseguir. Si se trata de un producto con el que se espere mucho impacto entre los usuarios, se deberá hacer un estudio de mercado.
2. Estudiar la viabilidad del sistema. Esto incluye la económica (analizar impacto del coste-beneficio), la técnica (ver si se puede realizar o no), la legal (determinar las infracciones o ilegalidades que pueda provocar el sistema) y las alternativas (estudiar las diferentes soluciones presentadas).
3. Hacer un análisis económico-técnico más profundo.
4. Determinar las funciones necesarias y asignarlas a elementos del sistema.
5. Crear un documento donde se especifique la definición del sistema. Este documento servirá como base para todo el desarrollo del sistema posterior.

Tanto si la solución es simple, como si es compuesta (sistema complejo) tendremos que realizar un análisis de los requerimientos del software. Una vez comprendamos el problema mediante el estudio del sistema hemos de plasmar esta comprensión es un documento. Esto es lo que se llama especificación de requerimientos. Los requerimientos que hemos de tener en cuenta pueden ser:

• Funcionales: describen las entradas y salidas del sistema, y las operaciones que se hacen entre ellas.
• No funcionales: definen las cualidades generales que ha de tener el sistema. En otras palabras, podemos definir estos requerimientos como los límites de las posibles soluciones. Estos pueden ser de rendimiento, de diseño (cumplimiento de estándares, requisitos hardware, control de errores, seguridad), de interfícies externas (todo lo relacionado con la interacción de las personas, con el hardware o con otro tipo de software), de calidad (que sea fácil de usar, de mantener, que sea ampliable...) o sobre decisiones de diseño (implementaciones de módulos).