MSc. Ing. Juan Carlos García O.

jgarciao@unab.edu.co

El proceso de desarrollo de software

Detalle del proceso de desarrollo de software

Análisis Orientado a Objetos

Documentos de análisis

Especificación de requisitos o requerimientos

Diagramas de casos de uso

Escenarios y sub-escenarios

Otras técnicas de análisis orientado a objetos

Resumen

Buena visión arquitectónica

No existe ningún camino bien definido para idear una

arquitectura. Tan sólo se pueden definir los atributos
de una buena arquitectura:

Capas de abstracción bien definidas.

Clara separación de intereses entre interfaz e
implementación.

Arquitectura simple.

Distinguir entre decisiones estratégicas y tácticas

Decisiones estratégicas

es aquella que tiene amplias implicaciones estratégicas e involucra
así a la organización de las estructuras de la arquitectura al nivel
más alto.

Decisiones tácticas

son las que sólo tienen implicaciones arquitectónicas locales, es
decir sólo involucran a los detalles de interfaz e implementación de
una clase.

Ciclo de vida incremental e iterativo

No deben ser anárquicos ni excesivamente rígidos.

Cada pasada por un ciclo análisis/diseño/evolución lleva a

refinar gradualmente las decisiones estratégicas y tácticas,
convergiendo en última instancia hacia una solución con los
requisitos reales de los usuarios finales (habitualmente no
expresados explícitamente por éstos)
Requisitos

Análisis

Diseño preliminar y detallado

Implementación & prueba unitaria

Integración

Mantenimiento
Diseño Análisis

Especificación
de requisitos

Implementación Versión 1
y pruebas Versión 2
Versión 3
ESFUERZO
Integración

Prueba

Diseño

Análisis

TIEMPO

Análisis

Características comunes de los documentos

Identificación

Título, descripción, versión, fecha, revisión, código del documento

Documentos de análisis

Especificación de requisitos o requerimientos

Diagramas de casos de uso

Escenarios y sub-escenarios

Diseño (preliminar y detallado)

Modelado de Clases, Objetos y mecanismos de colaboración

Diagramas de interacción

Diagramas de secuencia

Diagramas de colaboración

Diagramas de Clases y consulta de patrones de diseño

Diagramas de objetos

Modelado del comportamiento de clases y objetos

Diagramas de actividades

Diagramas de estados

Construcción del modelo físico

Diagramas de componentes

Diagramas de despliegue

Implementación

Las decisiones iniciales de implementación se toman

a partir de los diagramas de componentes y de
despliegue.

Se implementan las clases de un componente a partir

de los diagramas de clases y diagramas de objetos.

A partir de los diagramas de actividades y de los

diagramas de estados se implementa el
comportamiento de los métodos de cada clase.

Prueba

Prueba unitaria de cada clase

Prueba de módulos

Prueba de integración se realiza siguiendo los escenarios,
diagramas de interacción, actividades y estados

Mantenimiento

Informes de errores

Nueva especificación de requisitos. Nueva versión

Análisis Orientado a Objetos (AOO)[Booch94]

“es un método de análisis que examina los requisitos desde la perspectiva
de las clases y objetos que se encuentran en el vocabulario del dominio
del problema”

Documentos Básicos de Análisis Orientados a Objetos

Documentos de análisis

Especificación de requisitos o requerimientos

Diagramas de casos de uso

Escenarios y sub-escenarios

Prototipos y su evaluación

Todos los documentos deben estas

identificados y codificados

Análisis Orientado a Objetos

Es necesario identificar todos los elementos del proceso de
desarrollo de software de una forma unívoca.

Todos los documentos deben estar identificados.

Título

Debe reflejar de la mejor forma posible sus fines y su
funcionalidad.

Descripción

Autores

Versión

Notación decimal.

Revisión

Autores

Fecha

Código de cada documento o diagrama

Contiene la documentación que aporta el cliente
que encarga la aplicación

También contiene las actas de las reuniones de

trabajo del grupo de análisis:

Es necesario un secretario que tome acta

Es necesario aprobar el acta de cada reunión por todos los
miembros

Actividad

Por grupos discutir el Documento Vision (enlace a
documento aT3 en el aula virtual)

“La captura de requisitos es el proceso de averiguar,
normalmente en circunstancias difíciles, lo que se debe
construir” [Jacobson 1999, capítulo 6].

La captura de requisitos es complicada.

Los usuarios habitualmente no saben expresar
exactamente lo que quieren.

Es difícil tener una visión global del problema a resolver

La especificación de requisitos es un documento más
técnico y elaborado de los documentos de análisis.

Es importante codificar los requisitos para poder seguirlos
a lo largo del proceso de desarrollo de software.

Se puede utilizar una especificación jerárquica.

Están todos codificados por niveles, al igual que las leyes.

Se desea que en las actas quede reflejado lo más
exactamente posible el problema a resolver, y que en las
reuniones de análisis se determine exactamente que
requisitos se añaden o se eliminan.

Los requisitos relacionados se organizan dentro de un
mismo nivel.

Cada nivel 1

se puede hacer corresponder posteriormente con un caso
de uso.

Cada nivel 2

se puede hacer corresponder posteriormente con un
escenario.

Cada nivel 3

se puede hacer corresponder posteriormente con un sub-
escenario

Actividad

Por grupos discutir el Documento Vision (enlace a
documento Bogor en el aula virtual)

Un caso de uso captura algunas de las acciones y
comportamientos del sistema y de los actores.

El modelado con casos de uso fue desarrollado por

Ivar Jacobson [Jacobson 1992].

El sistema que se desea modelar se representa encerrado en
un rectángulo

Los actores son los que interactúan con el sistema.

Representan todo lo que necesite intercambiar con el sistema.

Un actor es una clase

Se diferenciará entre actores y usuarios

Un usuario es una persona que utiliza el sistema

Un actor representa el papel (rol) que una persona desempeña

Por ejemplo una persona puede ser usuario y administrador en un
sistema, unas veces actuará como usuario y otras como
administrador, pero deben contemplarse ambos actores

Los Casos de Uso es un camino específico para utilizar el
sistema.

Para cada Caso de Uso, Actor y Sistema se realiza una

descripción detallada.

Los Casos de Uso tan sólo indican opciones generales.

El diagrama de Casos de Uso es un diagrama sencillo

que tiene como finalidad dar una visión global de toda
la aplicación de forma que se pueda entender de una
forma rápida y gráfica tanto por usuarios como por
desarrolladores.
 Caso de uso 1

Caso de uso
Caso de uso 2

Caso de uso 3
Actor 3
Caso de uso 4

Caso de uso 5 ACTOR

Actor 1 Interacción
Caso de uso 6

Caso de uso 7

Actor 2
Limites del sistema Sistema
 PEDIDOS

INFORME PARA Gerente

GERENTE
Comprador
1. PEDIDOS
Escenario general donde se realizan todas las operaciones
relativas a pedidos: hacer, recibir, anular y devolver pedidos.
Todo es realizado por el Comprador.

2. INFORMES PARA EL USUARIO

Es un informe especialmente realizado para el gerente donde
este puede encontrar toda la información que pueda
necesitar en un momento determinado sobre las compras
realizadas por la empresa.
Sistema del cliente Sistema del servidor

Base de
Administración datos

Gestión de
clientes

Gestión
proveedores
Administrador
Gestión
pedidos

Gestión
Vendedor
almacén

Consultas

Nombre de Actor: Administrador

Definición: Es el encargado de administrar el

sistema. Tendrá todos los permisos y libertad de
movimientos por el sistema.

Notas:

El administrador es el encargado de manipular
la información contenida en el sistema.

Tiene acceso a toda la información del sistema
y es el único que puede modificar todo

Nombre de Actor: Vendedor

Definición: Es la persona que está en contacto

directo con los clientes. Tiene acceso limitado a las
operaciones del sistema.

Notas:

El vendedor no podrá dar de alta a clientes fijos,
pero si a clientes eventuales.

No podrá borrar clientes.

No tiene acceso a la gestión de proveedores.

SISTEMA SERVIDOR

El Sistema Servidor, (en nuestro caso particular) estará formado

por una máquina Windows NT Server.

El gestor de la base de datos (MySQL), junto a la propia base

de datos, se encuentran en el servidor Windows NT Server.

SISTEMAS CLIENTE
Los programas de la aplicación residen en la máquina «cliente»
Windows XP que conectan al servidor donde se encuentra instalada
el gestor de la base de datos junto con la base de datos
correspondiente

INTERFACES

INTERFAZ ADMINISTRADOR

El interfaz del Administrador le permite acceder a todas las opciones que
presenta la aplicación

INTERFAZ VENDEDOR

El Dependiente solamente tendrá acceso a algunas de las funciones que
soporta la aplicación y dentro de estas su capacidad de maniobra estará
limitada

Nombre del Caso de Uso 1

Gestión Clientes

Definición

Actualizaciones de la información acerca de los clientes de
Comercial XYZ.

Notas

Los clientes vienen definidos por: número_cliente, CC,
nombre, dirección, ciudad, teléfono.

Los clientes pueden ser fijos o eventuales.

Cada caso de uso da lugar múltiples escenarios.

Se codifican siguiendo la codificación de los casos

de uso.

Se estudia cada escenario utilizando guiones como

los que se usan en el cine.

Cada equipo que pasa por un escenario identifica

los objetos y sus responsabilidades, así como los
mecanismos que relacionan los objetos.

De los escenarios iniciales se puede pasar a otros
escenarios secundarios.

Los escenarios también se pueden utilizar para

probar el sistema en la fase de pruebas .

El estudio de los escenarios con detalle permitirá

enriquecer el Diccionario de clases.

No es necesario hacer todos los escenarios y sub-

escenarios posibles si se observa que no enriquecen
el diccionario de clases.
Numeración: 1.1
Titulo: Hacer pedido
Precondiciones: Sugerencias de compra
Quien Lo Comienza: Comprador
Quien Lo Finaliza: Comprador
Postcondiciones:
Excepciones:
Descripción: Son las operaciones de compra que realiza
el comprador.
Numeración: 1.2.
Título: Anular pedido
Precondiciones: Cambio de necesidades de la Empresa
Quien Lo Comienza: Comprador
Quien Lo Finaliza: Comprador
Postcondiciones:
Excepciones
Descripción: Esta operación la realiza el comprador
toma la decisión de anular un pedido que había
realizado con anterioridad.

Nombre de Escenario 1.1

Dar de alta un cliente eventual

Precondiciones

No existe ficha de cliente.

Post-condiciones:

Todos los datos se han introducido correctamente.

El numero de clientes se incrementa en uno

Excepciones:

Iniciado por

Dependiente/Administrador.

Finalizado por

Dependiente/Administrador.

Detalle operaciones:

Cliente acude a una tienda de la compañía.

Vendedor (ó Administrador) obtiene datos de cliente.

Vendedor (ó Administrador) introduce ficha en el sistema con los
datos número, CC, nombre, dirección, ciudad, teléfono.

Nombre de Escenario 1.2

Dar de alta un cliente fijo.

Precondiciones

No existe ficha de cliente.

Postcondiciones

Todos los datos se han introducido correctamente.

El número de clientes se incrementa en 1.

Excepciones

Iniciado por

Administrador

Finalizado por

Administrador.

Detalle operaciones:

Cliente acude a una tienda de la compañía.

Administrador obtiene los datos del cliente.

Administrador introduce ficha en el sistema con los datos número, CC,
nombre, dirección, ciudad, teléfono, y departamento.

caso de uso es la típica interacción entre un usuario
y un sistema informático.

Un actor es el papel que el usuario juega con

respecto al sistema. Un actor no tiene que ser un
humano, puede ser por ejemplo otro sistema
externo que pide información al sistema actual.

La relación <<extend>> se utiliza cuando un caso

de uso es similar a otro caso de uso pero se le
añade alguna característica nueva

Análisis OO mediante fichas CRC
(Clases/Responsabilidades/Colaboradores).

Descripción informal en lenguaje natural.


Es una forma simple de analizar escenarios

Son muy útiles para la enseñanza del AOO, DOO y POO

Facilitan las “tormentas de ideas” y la comunicación entre

desarrolladores

Se crea una ficha para cada clase que se identifique como

relevante en el escenario

A medida que el equipo avanza puede dividir las

responsabilidades

Las fichas CRC pueden disponerse espacialmente para

representar relaciones de colaboración

Las fichas CRC también se pueden colocar para expresar
jerarquías de generalización/especialización.

No están contempladas en UML.

FICHA CRC (ANVERSO Y REVERSO)

Clase Clase

Responsabilidades Superclase
Subclase

Colaboraciones Atributos
Clase: Reunión

Responsabilidades
Planificar
Comprobar la sala asignada
Conocer hora de comienzo
Conocer la fecha
Conocer número de asistentes
Conocer equipamiento necesario

Colaboraciones
Sala de conferencias
Organizador de reuniones

Clase: Reunión

Superclase:
Subclases: Reunión de trabajo, Junta de Escuela, Clase de un curso

Atributo:
Orden del día
Lugar
Fecha
Hora de inicio
Asistentes
Equipo necesario

Subrayar los nombres y los verbos de la descripción del
problema

Los nombres representan los objetos candidatos

Los verbos representan las operaciones candidatas
– Ventajas

•Obliga al desarrollador a trabajar sobre el vocabulario del
espacio del problema

•Es sencillo

•Es didáctico
– Inconvenientes

•No es riguroso, al ser el lenguaje natural ambiguo

•Es compleja su aplicación a grandes proyectos

No existen recetas fáciles para el análisis de
software.

La correcta definición de los requisitos y su

seguimiento en el proceso de desarrollo es uno de
los factores fundamentales de la calidad del
software.

Los escenarios son una potente herramienta para el

análisis orientado a objetos, y pueden utilizarse para
guiar los procesos de análisis clásico, análisis del
comportamiento y análisis de dominios.

Las abstracciones clave reflejan el vocabulario del
dominio del problema y pueden ser descubiertas en
el dominio del problema, o bien ser inventadas
como parte del diseño.

Los mecanismos denotan decisiones estratégicas

de diseño respecto a la actividad de colaboración
entre muchos tipos diferentes de objetos.

El único artefacto que tiene UML a nivel de análisis

son los Diagramas de Casos de Uso.