Mostrando entradas con la etiqueta UML. Mostrar todas las entradas
Mostrando entradas con la etiqueta UML. Mostrar todas las entradas

jueves, 24 de octubre de 2013

Ingeniería de software : Un enfoque profesional

Roger S Pressman.



                                                           Ingenieria de Software

Este libro lleva más de 20 años en el mercado renovándose con nuevas ediciones, ya va por la 7ª Edición aunque renovada, las ediciones antiguas siguen siendo igualmente válidas en muchos aspectos pues cada nueva edición actualiza un contenido ya bastante completo.

Estas últimas ediciones se renuevan sobre todo en lo referente al aspecto de las aplicaciones web, cada vez más presente en el mercado hoy en día. También se han mejorado y aumentado significativamente los contenidos de UML. Aunque para aprender UML en profundidad recomiendo el libro de sus creadores


miércoles, 22 de mayo de 2013

Análisis orientado a objetos (AOO) IV


Definición de estructuras y jerarquías

Una vez generado el modelo CRC hay que centrarse en la estructura de las clases con su correspondiente jerarquía. Se usa para ello la notación UML para representar gráficamente la jerarquía entre las clases obtenidas del modelo CRC. La flecha representa la dependencia jerárquica. La jerarquía mostrada se ha extraído de las tarjetas CRC generadas anteriormente.

             modelo de clases orientado a objetos

Definición de Subsistemas

Un modelo de análisis puede tener cientos de clases, en este caso resulta útil dividir ciertos grupos de clases en subsistemas. Para ello se eligen grupos de clases con un conjunto de responsabilidades similares. En realidad consisten en un escalón más en la abstracción para hacer más manejables grandes proyectos. En UML los subsistemas se llaman paquetes. Un subsistema tratado en su conjunto también contiene un conjunto de responsabilidades y posee sus propios colaboradores externos. En el sistema CRC se puede incluir un índice que defina el subsistema al que pertenece cada tarjeta, añadiendo también las responsabilidades a cumplir (contratos) y otros subsistemas si los hay. Por ejemplo el sistema creado anteriormente para una biblioteca se puede representar en UML como un rectángulo con dos líneas debajo para representar un subsistema de un conjunto más amplio, por ejemplo como perteneciente a una gran empresa.

              Análisis orientado a objetos, subsistemas

El modelo Objeto-Relación

El siguiente paso al CRC es definir las clases colaboradoras que ayudan a realizar cada responsabilidad de una clase dada. Este paso establecerá las conexiones entre las diferentes clases. Existe una relación, asociación o conexión entre dos clases cualesquiera que estén conectadas. La relación más común de todas en la binaria que se da entre dos clases, esta es direccional, es decir tiene una parte cliente y otra servidora.
Las relaciones se pueden derivar analizando los verbos de los enunciados. Se aíslan verbos que sugieren:

- localizaciones físicas (cerca de, contenido en)

- comunicaciones (obtenido de, transmite)

- propiedad (se compone, incorporado por)

- cumple una condición (coordina, controla, dirige)

Una vez definidas las relaciones se conectan los objetos a través de relaciones con nombres y especificando la cardinalidad.

Para obtener el modelo se usan las tarjetas CRC, Si existe alguna relación se dibujan los objetos conectados por líneas, para evitar ambigüedades se pune una punta de flecha apuntando del cliente al servidor. Finalmente se evalúa la cardinalidad de cada extremo.
El esquema en UML quedaría de este estilo.

          Análisis orientado a objetos. Esquema UML



lunes, 29 de abril de 2013

Análisis orientado a objetos (AOO).

Introducción


El objetivo del Análisis Orientado a Objetos (AOO) es desarrollar un modelo que describa el software de computadora necesario para satisfacer los requisitos definidos por el cliente. El modelo de análisis contiene el funcionamiento y el comportamiento de los elementos del modelo de objetos.

Nadie tiene muy claro por qué el Análisis Orientado a Objetos ha tardado tanto tiempo en ser aplicado a pesar de que maneja conceptos que aprendimos en la guardería como objeto, clase, miembro etc. No existe un acuerdo sobre los conceptos que sirven de base para el AOO, aunque se repiten a menudo un número de ideas clave.

El propósito es definir todas las clases, atributos, operaciones y relaciones de comportamiento asociado entre ellos que sean relevantes al problema que se va a resolver. Para realizar dicho análisis se deben ejecutar las siguientes tareas:

-Identificar los escenarios o casos de uso.


-Identificar las clases,


-Definir sus atributos y métodos.


-Especificar la jerarquía entre las clases.


-Representar las relaciones entre los diferentes objetos del sistema.


-Modelar el comportamiento de cada objeto.


-Repetir iterativamente las tareas anteriores hasta completar el modelo.

UML


Existían varios métodos para realizar AOO pero esos métodos se recombinaron en uno sólo llamado UML (Lenguaje de Modelo Unificado) este sistema aúna todos los procesos comunes y trata de tomar de cada método lo mejor. UML se caracteriza por cinco vistas independientes de un mismo problema, cada vista contiene un enfoque diferente del problema y lo muestra con gráficos de diferentes tipos.

Las cinco visiones diferentes de UML son:

Vista del usuario: representa el sistema desde la perspectiva de los usuarios (llamados actores en UML). Para este tipo de vista se utiliza el diagrama de casos de uso.


Vista estructural: modela la estructura estática (clases, objetos y sus relaciones).

Vista del comportamiento: representa los aspectos dinámicos o de comportamiento del sistema. También muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en las vistas anteriores.

Vista de implementación: aquí se representan tal y como van a ser implementados los aspectos estructurales y de comportamiento.

Vista del entorno: muestra como irán los módulos implementados dentro del proyecto físico y las relaciones entre los diferentes módulos.

El AOO se centra en las vistas del usuario y estructural.

El DOO (modelo de diseño Orientado a Objetos) se centra más en las vistas del comportamiento y entorno.

Análisis del dominio


Es la primera actividad técnica a la hora de comenzar un nuevo proyecto. El objetivo de este análisis es definir las clases y objetos que están presentes en el dominio del problema propuesto. Esto dependerá del tipo de enfoque que se dé al problema o del área de negocio que se desea modelizar y se encuentra encuadrado dentro de un nivel medio de abstracción. Sirve para crear una biblioteca de clases que posteriormente podrán ser reutilizables (componentes).


Para ello cuando se diseñan las clases hay que tener en mente que no se realizarán con el único objetivo de integrarlas en una aplicación concreta, sino que deben diseñarse pensando en una posterior reutilización, esto es lo que llamamos análisis del dominio.

Por tanto se trata de identificar los requisitos comunes de una aplicación específica con vistas a su reutilización posterior dentro de un dominio de aplicación específico.

Un analista de dominio debe verse a sí mismo como un diseñador de herramientas para que los demás trabajen con ellas.



Definir el dominio


Consiste en aislar el área del negocio, se extraen las especificaciones y diseños de código que ya existan, clases, interfaz gráfica y clases de acceso a bases de datos, bibliotecas comerciales, también políticas, procedimientos, estándares, guías etc. En definitiva todo lo relevante para el proyecto. Se clasifican los elementos definiendo categorías de elementos y la nomenclatura de cada una de ellas.

Se deben identificar los objetos candidatos, ver si dichos objetos son reutilizables o adaptarlos para que lo sean y definir qué porcentaje de la aplicación podrá construirse con estos objetos reutilizables.

Se trata de desarrollar un modelo de análisis para los objetos que posteriormente servirá como base para la construcción de los objetos del dominio y su reutilización.

Componentes genéricos


Se trata de desarrollar un modelo del mundo real, dejando los detalles para más adelante. Se distingue entre componentes estáticos (que no cambian durante la vida de la aplicación) y componentes dinámicos (que se centran en el control y dependen del tiempo y de los sucesos).

Vista estática de clases, las que persisten a lo largo de toda la vida de la aplicación.

Vista estática de atributos, para definir las clases anteriores.

Vista estática de relaciones, para definir las conexiones e interacciones entre los objetos anteriores.

Vista estática de comportamientos, consiste fundamentalmente en un modelo de casos de uso que define una secuencia de operaciones genérica.

Vista dinámica de comunicación, define la comunicación dinámica entre objetos definiendo los mensajes que producen transiciones de un estado a otro.

Vista dinámica de control y tiempos, describe el tipo y duración de los sucesos que provocan la transición de estados entre ellos.