Aoo05

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 11 Slide 1
Análisis y Diseño

El análisis se centra en la investigación del
problema, no en la manera de definir la
solución.
Ej. Si se necesita un sistema de biblioteca
Cuales son los procesos de la organización
que se relacionan con su uso?
Qué es análisis?

El diseño pone en relieve una solución lógica:
como el sistema cumple con los
requerimientos.
Ej. De qué manera el sistema capturará y
registrará los préstamos de libros?
La esencia de estas actividades consiste en
situar el dominio del problema y la solución
lógica dentro de la perspectiva de los objetos.
Qué es diseño?

Durante el análisis se procura identificar y
describir objetos – o conceptos – dentro del
dominio del problema.
Durante el diseño se procura definir objetos
lógicos del software
Análisis y diseño

Análisis y diseño

Análisis y diseño
Para entender los requerimientos se necesita conocer
los procesos de dominio y el ambiente externo , o sea
los factores externos que participan en el proceso.
Dichos procesos se pueden expresar en forma de casos
de uso, los cuales son una descripción narrativa del
proceso de dominio en un formato estructurado de
prosa,

Análisis y diseño; Ejemplo
El juego de dados:
Caso de uso: juega un juego
Participantes: jugador
Descripción: Este caso de uso comienza cuando el
jugador recoge y hace rodar los dados. Si los puntos
suman 7 gana y si suman cualquier otro número,
pierde.

Análisis y diseño
El modelo conceptual o modelo de análisis es una representación de
conceptos u objetos en el dominio del problema, como libro,
biblioteca.
Debe limitarse el esfuerzo aplicado a la creación de un modelo
conceptual preliminar en la fase de planificación y elaboración, por
la complejidad que pueden tener.
Puede ser elaborado una vez definidos los requerimientos o antes
de los ciclos de desarrollo.

El modelo conceptual muestra los conceptos jugador,
dados, juego de dados, sus asociaciones atributos.

El Diagrama de colaboración presenta el flujo de
mensajes entre instancias y la invocación a los
métodos.

Para definir una clase en preciso contestar varias
preguntas:
Cómo se conectan unos objetos con otros?
Cuales son los métodos de una clase?
El jugador requiere de un método jugar y el dado
requiere de un método lanzar.

El modelo de diseño o diagrama de diseño de clases
describe componentes de software.

Comparación AD OO y estructurado

Construcción de un modelo conceptual
El modelo conceptual explica los conceptos
significativos en el dominio del problema, es el artefacto
más importante a crear durante el análisis orientado a
objetos.
(Los casos de uso son importantes pero no son
realmente orientados a objetos)
La cualidad esencial que debe ofrecer un modelo
conceptual es que representa cosas del mundo real, no
componentes del software.

El modelo conceptual es un diagrama de estructura
estática, es decir, no define ninguna operación.
ELEMENTOS:
1. Conceptos
2. Asociaciones
3. Atributos de los conceptos

1. Conceptos
Un concepto es una idea, evento u objeto.
Formalmente se lo define a partir de:
Símbolo: palabras o imágenes que representan un
concepto.
Intensión: la definición de un concepto
Extensión: el conjunto de ejemplos a que se aplica
el concepto.

Ejemplo: Transacción venta.
Símbolo: Lo denominamos VENTA
Intensión: Representa la transacción de venta,
tienen hora y fecha
Extensión: conjunto de todas las ventas

Identificación de conceptos
1. Lista des categorías comunes
Objetos físicos o tangibles
Especificaciones de diseño o descripciones de
cosas
Lugares
Transacciones
Línea de transacciones
Papel(rol-cargo) de personas
Contenedores de otras cosas
Etc, etc, etc

Identificación de conceptos
2. Identificación de frases nominales
Consiste en identificar las frases nominales
(sustantivos) en las descripciones textuales del
dominio del problema y considerarlas conceptos o
atributos.
Esta técnica es muy útil cuando se empieza a entender
el enfoque de orientación a objetos

Se recomienda combinar esta técnica con la lista de
categorías

Ejemplo: punto de venta
Conceptos:
• TPDV, producto, tienda, venta, pago
• Catalogo de productos , especificación del producto
• Venta línea de productos
• Cajero, cliente, gerente

Asociaciones
Es una relación entre dos conceptos que indica alguna
conexión significativa entre ellos
En lenguaje UML se denominan relaciones
estructurales entre objetos de diversos tipos.

Asociaciones
Comience por agregar las asociaciones utilizando la
lista de asociaciones comunes:

Asociaciones - Multiplicidad
La multiplicidad define cuantas instancias de tipo A
pueden asociarse a una instancia del tipo B en
determinado momento.

Asociaciones – Múltiples entre conceptos
Dos conceptos pueden tener varias asociaciones entre
ellos.

Asociaciones – ejemplo

Modelo conceptual – punto de venta

Modelo conceptual – atributos
Un atributo es un valor lógico de un dato u objeto
Pertenece a un concepto
Tiene un tipo que define los posibles valores

Modelo conceptual – atributos – tipos
Tipos más comunes (valores puros de datos)
Los atributos deberían ser simples o valores puros de datos
Si es un valor complejo es mejor expresarlo como
asociación.

Ejemplo Modelo conceptual – atributos

Descripción del comportamiento
Durante el análisis, se incluye modelos orientados a
describir el comportamiento del sistema. Uno de ellos
es el diagrama de secuencia del sistema.
Antes de iniciar el diseño lógico de cómo funcionará la
aplicación de SW es necesario investigar y definir el
comportamiento del sistema como una “caja negra”
EL comportamiento del sistema es una descripción de que
es lo que hace, sin explicar como lo hace.

El diagrama de secuencia del sistema muestra en un escenario, los
eventos generados por eventos externos, su orden y los eventos
externos del sistema Ej. Caso comprar productos

EVENTOS Y OPERACIONES
Evento de un sistema es un hecho externo de entrada que un actor
produce en un sistema.
Una operación de un sistema es una acción que este ejecuta en
respuesta a un evento del sistema
Ej, un cajero genera un evento “introducir producto”, causa la ejecución
de la operación “introducir producto”
Los nombres del evento y la operación generalmente son iguales,
La diferencia es que el evento es el estímulo y la operación es la
respuesta.
(igual que los mensajes y los métodos en las clases y objetos)

OPERACIONES
Para determinar las operaciones del sistema se identifican los eventos.
Ej,
EfectuarPago(CUP, Cantidad)
TerminarVenta()
EfectuarPago(monto)

Diagramas de secuencia del sistema.
1.- determinar actores
2.- Los eventos (y sus operaciones asociadas) deben
expresarse en el nivel de propósito. El nombre
comúnmente empieza con un verbo (agregar, introducir,
terminar, efectuar) ya que recalca que los eventos están
orientados a comandos.
Seleccionar el nivel mas alto u objetivo para dar el nombre
a operaciones: ej: respecto a la operación que captura
el pago:
IntroducirImporteOfrecido(Monto) deficiente
IntroducirPago(monto) mejor
EfectuarPago() mejor aún

Modelo de análisis
El modelo de análisis está compuesto de:
Modelo de casos de uso de análisis (dinámico)
Casos de uso de alto nivel o esenciales
Diagramas de casos de uso
Modelo conceptual (estático)
Modelo de comportamiento (dinámico)
Diagramas de secuencia del sistema
Contratos para las operaciones del sistema
Modelo de estado del análisis (dinámico)
Diagramas de estado para conceptos y casos de uso

Modelo de análisis
El modelo de análisis está compuesto de:

Modelo de análisis
Contratos
Los contratos contribuyen a definir el comportamiento del
sistema
El contrato es un documento que describe lo que una
operación se propone lograr
Se redacta en estilo declarativo, enfatizando lo que se
conseguirá y no como se conseguirá
Suelen expresarse a partir de los cambios de las
precondiciones y post-condiciones.
EL contrato de operación del sistema describe cambios de
estado del sistema total cuando se llama una de sus
operaciones.

Modelo de análisis
Elementos de un contrato

Modelo de análisis
Ejemplo Contratos de la operación
“IntroducirProducto”

Modelo de análisis
Diagramas de estado
Muestran como los objetos cambian de estado en
respuesta a los eventos.
Los diagramas de secuencia se utilizan para modelar el
comportamiento combinado de un grupo de objetos,
pero también son útiles para resumir el comportamiento
de un solo objeto como respuesta a los diversos
mensajes que puede procesar. Para esto se utiliza un
diagrama de estado.

Modelo de análisis
Ejemplo Diagramas de estado
transmission done
calibrate ()
test ()star tup ()
shutdown ()
calibration OK
test complete
weather summary
complete
clock collection
done
Operation
repor tWeather ()
Shutdown Waiting Testing
Transmitting
Collecting
Summarising
Calibrating

Diseño Orientado a Objetos
DOO comprende el desarrollo de un modelo
orientado a objetos de un sistema SW para
implementar los requerimientos
identificados.
Los objetos en un DOO están relacionados con
la solución del problema a resolver.

Actividades del proceso DOO
Las actividades principales en el proceso de DOO
incluyen:
Contexto: Define el contexto y modos de uso del
sistema;
Arquitectura: Diseña la arquitectura del sistema;
Objetos: Identifica los objetos principales del
sistema;
Modelos: Desarrolla los modelos de diseño;
Interfaces: Especifique interfaces del objeto.

Modelo de diseño
Resumen del diseño

Architecture
Una vez que las interacciones entre el sistema y su
ambiente se han entendido, se usa esta información
por diseñar la arquitectura del sistema.
Debe haber normalmente no más de 7 entidades en
un modelo arquitectónico.

Weather station architecture
Weather station
Manages all
external
communications
Collects and
summarises
weather data
Package of
instruments for raw
data collections
« subsystem»
Data collection
« subsystem»
Instruments
« subsystem»
Interface
Una arquitectura por capas es apropiado para la estación de tiempo
Capa de la interface por manejar comunicaciones;
Capa de colección de datos para los instrumentos gerente;
Capa de los instrumentos para los datos colectivos.

Diseño de la Arquitectura
Una etapa inicial del proceso de diseño del
sistema.
Representa el vínculo entre el pliego de
condiciones y procesos de diseño.
A menudo llevan a cabo paralelamente con
algunas actividades de especificación de
requerimientos
Comprende la identificación de los
principales componentes del sistema y sus
comunicaciones.

Ventajas de una arquitectura
explícita
Aporta en:
Comunicación con stakeholders
La arquitectura puede ser utilizado como un centro
de la discusión por las partes interesadas del
sistema.
Análisis del sistema
Significa que el análisis de si el sistema puede
cumplir con sus requisitos no funcionales es posible.
Reutilización a gran escala
La arquitectura puede ser reutilizable en una serie
de sistemas.

Architecture and system characteristics
La arquitectura del sistema afecta al rendimiento, solidez,
grado de distribución y mantenibilidad de un sistema.
Rendimiento
Identificar las operaciones críticas y minimizar las
comunicaciones. Utiliza grandes componentes.
Protección
Usar una arquitectura en capas, con los elementos críticos en las
capas internas para protegerlos.
Seguridad
Localizar Operaciones críticas para la seguridad en un pequeño
número de sub-sistemas o en un subsistema único.
Disponibilidad
Incluir componentes redundantes y mecanismos de tolerancia a
fallos.
Mantenibilidad
Usar componentes reemplazables.

Estructura del sistema
Descomposición del sistema en subsistemas
que interactúan.
El diseño arquitectónico se expresa en un
diagrama de bloques de presentar una visión
general de la estructura del sistema.
Los modelos más específicos muestran la
como los sub-sistemas comparten datos, se
distribuyen e interacción con los demás y
también pueden ser desarrollados.

Sistema robótico de control de
empaquetado
Vision
system
Object
identifica tion
system
Arm
contr oller
Gripper
contr oller
Packaging
selection
system
Packing
system
Conveyor
contr oller

Architectural design decisions
1. ¿Hay una arquitectura de la aplicación genérica que puede
usarse?
2. ¿Cómo se distribuirá el sistema entre varios procesadores?
3. ¿Qué estilos arquitectónicos son apropiados para el sistema?
4. ¿Qué aproximación se usará para estructurar el sistema?
5. ¿Cómo se descompondrá en los módulos las unidades
estructurales del sistema?
6. ¿Qué estrategia debe usarse para controlar el funcionamiento
de las unidades del sistema?
7. ¿Cómo se evaluará el diseño arquitectónico?
8. Cómo debería documentarse la arquitectura del sistema?

Estilos de arquitectura
El modelo arquitectónico de un sistema
puede conformar a modelo arquitectónico
genérico o estilo.
Un conocimiento de estos estilos puede
simplificar el problema de definir
arquitecturas del sistema.
Sin embargo, mayoría de los sistemas
grandes es heterogéneo y no sigue un solo
estilo arquitectónico.

Modelo de Arquitectura
Documenta un diseño arquitectónico y pueden tener
las siguientes perspectivas:
1. Como un Modelo estructural estático que muestra
los principales componentes del sistema.
2. Como Modelo del procesos dinámicos que muestra
la estructura de los procesos del sistema.
3. Como Modelo de interfaz que define interfaces de
los sub-sistema.
4. Las relaciones diseñan como un modelo de flujo de
datos entre subsistemas.
5. Modelo de la distribución que muestra cómo los
sub-sistemas son distribuídos entre las
computadoras.

Diseño de subsistemas
En el diseño de Sistemas OO se particiona
el modelo de análisis, para definir
colecciones congruentes de clases,
relaciones y comportamiento. Estos
elementos de diseño se definen como
subsistema.
En general todos los elementos de un
subsistema comparten alguna propiedad en
común. Y se integran para completar la
misma función. Los subsistemas se
identifican por los servicios que proveen.

Criterios de Diseño de
subsistemas
Interfaz definida y reducida con el resto del
sistema.
Las clases dentro del subsistema deben
colaborar solo con otras clases dentro del
subsistema (a excepción de las clases de
comm)
El número debe ser bajo
Un subsistema puede ser particionado para
reducir complejidad.

Estratificación por capas
Cada capa contiene uno o más subsistemas.
Cada capa representa un nivel de abtracción
diferente para completar la función del
sistema
El enlace puede ser cliente-servidor o peer-
to-peer

Arquitectura de 3 capas
Capa de presentación.- interfaz de usuario,
ventanas, reportes, etc.
Capa de aplicación.- tareas y reglas que
rigen el proceso.
Capa de base de datos.- mecanismo de
almacenamiento.

Arquitectura de 3 capas

Arquitectura Multicapas
La capa de aplicaciones se divide: objetos de
dominio y servicios.
Capa de presentación.- interfaz de usuario
Capa de dominio.- servicios de alto nivel
(pago, venta)
Capa de Servicios.- incluye servicios de bajo
nivel. Interfaz de la DB, Generador de
reportes, comunicaciones.
Capa de base de datos.- procesamiento de
datos.

Arquitectura Multicapas

Paquetes UML
Un paquete es un conjunto de cualquier tipo
de elemento de un modelo: clases, casos de
uso, diagramas de colaboración u otros
paquetes.
El paquete de más alto nivel es el sistema.

Paquetes UML
Las capas conforman los paquetes UML de
menor nivel. Conformando un diagrama de
paquetes de la arquitectura,

Ejemplo arquitectura

Modelo de diseño
Continuación del diseño

Modelo de diseño
El modelo de diseño muestra los objetos y clases de objetos
y las relaciones entre estas entidades. Para esto se
incluyen dos tipos de diagramas: estáticos y dinámicos
Los modelos estáticos describen la estructura estática del
sistema en términos de clases del objeto y relaciones:
modelo de arquitectura, modelo de clases, esquema de
bases de datos.
Los modelos dinámicos describen las interacciones
dinámicas entre los objetos: casos de uso reales, contratos,
diagramas de interacción y colaboración, diagramas de
estado.

Diagramas de interacción y contratos
para métodos y operaciones
En la práctica, los diseñadores se percatan de que la
preparación de los diagramas de interacción es uno de
los pasos más lentos.
La asignación de responsabilidades y la elaboración de
los diagramas de interacción representan uno de los
pasos más importantes en la fase de diseño.

Los diagramas de interacción describen gráficamente la
solución –a partir de los objetos en interacción- que satisfacen
estas responsabilidades y poscondiciones.
En los contratos se incluye una conjetura inicial sobre las
responsabilidades y las poscondiciones de las operaciones inicio,
introducirProducto, terminarVenta y efectuarPago.

La calidad de diseño de la interacción de los objetos y la asignación
de responsabilidades presentan gran variación.
• Las decisiones poco acertadas dan origen a sistemas y
componentes frágiles y difíciles de mantener, entender, reutilizar
o extender.
• Una implementación hábil se funda en los principios cardinales
que rigen un buen diseño orientado a objetos.

• Los diagramas de interacción son algunos de los artefactos más
importantes que se preparan en el análisis y diseño orientados a
objetos.
• Es muy importante asignar acertadamente las responsabilidades
al momento de elaborar los diagramas de interacción.
• El tiempo y el esfuerzo que se dedican a su elaboración, así como
un examen riguroso de la asignación de responsabilidades, deberían
absorber parte considerable de la fase de diseño de un proyecto.
• UML define algunos patrones, principios y expresiones
especializadas codificados que sirven para mejorar la calidad del
diseño, llamados PATRONES GRASP

Los patrones GRASP son parejas de problema solución con un
nombre, que codifican buenos principios y sugerencias relacionados
frecuentemente con la asignación de responsabilidades.
Pregunta: ¿Qué son los patrones GRASP?
Respuesta: Los patrones GRASP describen los principios
fundamentales de la asignación de responsabilidades a
objetos, expresados en forma de patrones.
GRASP es un acrónimo que significa General Responsibility
Asignment Software Patterns (patrones generales de software para
asignar responsabilidades).

Patrones GRASP
• Experto
• Creador
• Bajo Acoplamiento
• Alta Cohesión
• Controlador.

Diagramas de clases
Una vez terminados los diagramas de interacción podemos
identificar la especificación de las clases de software (y las
interfaces) que participan en la solución de software y
complementarlas con detalles de diseño, por ejemplo los métodos.
Su preparación exige crear antes:
• Modelo conceptual: a partir de éste el diseñador agrega detalles a
la definición de las clases.
• Diagramas de interacción: a partir de ellos el diseñador identifica
las clases de software que intervienen en la solución, así como los
métodos de las clases.

Diagramas de clases
El diagrama de clases de diseño describe gráficamente las
especificaciones de las clases de software y de las interfaces en una
aplicación.
Normalmente contiene la siguiente información:
• clases, asociaciones y atributos
• interfaces, con sus operaciones y constantes
• Métodos
• información sobre los tipos de los atributos
• Navegabilidad (visibilidad de los atributos)
• dependencias.

Diagramas de clases
1. Identifique todas las clases que participan en la solución del software.
Para ello analice los diagramas de interacción.
2. Dibújelas en un diagrama de clases.
3. Duplique los atributos provenientes de los conceptos asociados del
modelo conceptual.
4. Agregue los nombres de los métodos analizando los diagramas de
interacción.
5. Incorpore la información sobre los tipos a los atributos y a los
métodos.
6. Agregue las asociaciones necesarias para dar soporte a la visibilidad
requerida de los atributos.
7. Agregue flechas de navegabilidad a las asociaciones para indicar la
dirección de la visibilidad de los atributos.
8. Agregue las líneas de relaciones de dependencia para indicar la
visibilidad no relacionada con los atributos.

Diagramas de clases

Aoo05

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (7)

Destacado

Destacado (19)

Similar a Aoo05

Similar a Aoo05 (20)

Último

Último (12)

Aoo05