G U I A D E E S T U D I O S
CARRERA: TECNOLOGIA EN ANALISIS DE SISTEMAS
SEMESTRE: CUARTO
ASIGNATURA: ANALISIS Y DISEÑO ORIENTADO A
OBJETOS
Cód. Asig.: PS – S4 - ANOO
CRÉDITOS: 4 HORAS: 64
DOCENTE RESPONSABLE: ING. JORGE JARAMILLO
ALBA
Ing. Jorge Jaramillo Alba
2
INTRODUCCIÓN:
Con la finalidad de afianzar los conocimientos de cada una de las asignaturas
correspondientes al estudio de la carrera de Análisis en Sistemas, se han desarrollado
un conjunto de guías de estudio, las mismas que van a fomentar y cimentar los
conocimientos que el estudiantes debe adquirir, específicamente en este documento,
acerca de Análisis y Diseño Orientado a Objetos.
El estudio de Análisis y Diseño Orientado a Objetos, cuyo prerrequisito es Análisis de
Sistemas y Técnicas de Documentación, inicia con el aprendizaje y el desarrollo de
habilidades concernientes al desarrollo de un proyecto de software orientado a objetos.
El objetivo de esta asignatura es desarrollar software de calidad que resuelvan
problemas de todo tipo, aplicando métodos, técnicas y herramientas del proceso de
desarrollo de software como análisis, diseño e implementación y los conocimientos
adquiridos de programación, sistemas operativos, bases de datos, entre otras, para lo
cual dividiremos el contenido temático en cuatro temas que son:
TEMA I: EL PROCESO DE ANALISIS PREVIO AL DISEÑO DE SOFTWARE. Que permitirá
caracterizar los conceptos, elementos y procesos del Software.
TEMA II: DISEÑO ESTRUCTURA DEL SOFTWARE. Donde se analizarán aspectos
relacionados a la construcción de las bases para el desarrollo del software.
TEMA III: FUNDAMENTOS DEL DISEÑO ORIENTADO A OBJETOS. Aspectos
relacionados al Análisis y Diseño enfocados en la técnica orientada a objetos.
TEMA IV: DISEÑO DE DIAGRAMAS ORIENTADOS A OBJETOS. Donde se desarrollará
esquemas arquitectónicos para el desarrollo de software orientado a objetos.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
3
ÍNDICE
Introducción…………………………………………………………………………….
2
Syllabus…………………………………………………………………………………
4
Orientaciones para el uso de la guía de estudio
12
Desarrollo de Actividades:
Tema 1………………………….………………...…...……………………………….
14
Tema 2………………………….………………...…...……………………………….
29
Tema 3………………………….………………...…...……………………………….
38
Tema 4………………………….………………...…...……………………………….
53
Ing. Jorge Jaramillo Alba
4
SYLLABUS DE LA ASIGNATURA I. DATOS INFORMATIVOS
CARRERA: Análisis de Sistemas
NIVEL: Tecnológico
TIPO DE CARRERA: Tradicional
NOMBRE DE LA SIGNATURA: Análisis y Diseño Orientado a Objetos
CÓD. ASIGNATURA: PS-S4-ANOO
PRE – REQUISITO: Análisis de Sistemas,
Técnicas de Documentación
CO – REQUISITO: Introducción a Sistemas Operativos
Sistemas Cliente Servidor
Programación en C-Shell
# CRÉDITOS: 4 TOTAL HORAS: 64
SEMESTRE: Cuarto
PERIODO ACADÉMICO: Octubre 2015 – Marzo 2016
MODALIDAD: Presencial
DOCENTE RESPONSABLE: Ing. Jorge Jaramillo Alba.
I. FUNDAMENTACIÓN
Los fundamentos acerca de cómo usar las computadoras dentro de la organización para
mejorar la productividad y lograr mejorar los objetivos de la misma obligan al conocimiento de
la teoría necesaria para entender al usuario potencial y a la tecnología, para integrar un mejor
diseño de los sistemas de información. Un panorama comprensible del material relacionado
con el análisis y diseño de sistemas, explicando que es un proceso en el que se aplican
muchas herramientas para mejorar el trabajo en las instituciones o los negocios mediante la
implementación o el cambio de los sistemas de información.
En la asignatura se hace énfasis sobre las funciones del analista, de la operación de las
organizaciones y de la relación que con ellas tienen los sistemas de información: como
determinar si un proyecto de sistemas es digno de emprenderse, y por último, cómo coordinar
un proyecto de sistemas. En el programa se estudian las tres funciones del analista: consultor,
especialista de apoyo y agente del cambio.
El diseño de sistemas de software es una disciplina o área de la informática, que ofrece
métodos y técnicas para desarrollar y mantener software de calidad que resuelven problemas
de todo tipo. Trata con áreas muy diversas de la informática y de las ciencias de la
computación, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de
sistemas de información y aplicable a una infinidad de áreas tales como: educación, negocios,
investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología,
el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
5
Los modelos de procesos de software, métodos de desarrollo de software y herramientas de
software se han adoptado con éxito en el amplio espectro de las aplicaciones educativas. Los
gestores y usuarios reconocen la necesidad de un enfoque más disciplinado del software.
A partir de lo anteriormente expuesto, nace la necesidad de diseñar software que permita el
desarrollo de aplicaciones de calidad para la solución de un problema determinado, siendo el
objeto de la asignatura el proceso del diseño de software.
II. OBJETIVO
Diseñar software confiable, consistente y de calidad mediante la aplicación de técnicas y
herramientas informáticas que permitan el modelamiento responsable y honesto de soluciones
informáticas a los problemas de la realidad social.
III. OBJETIVOS ESPECÍFICOS
Retroalimentar los procesos previos al diseño de software mediante el repaso de las
etapas del análisis de sistemas que permitan la fundamentación de responsable de las
bases para un buen análisis y diseño de software orientado a objetos.
Esquematizar el diseño estructurado del software mediante el estudio de componentes
y procesos relativos al diseño que permitan el aprendizaje perseverante de los
componentes válidos del análisis y diseño orientado a objetos.
Esquematizar procesos mediante la diagramación y representación gráfica de los
elementos del software que permitan la implementación de la creatividad en el diseño.
Diagramar procesos del software mediante el uso de herramientas adecuadas que
permitan la obtención puntual de los elementos del diseño del software.
IV. CONTENIDOS
Conocimientos Habilidades Valores
Unidad didáctica I
El proceso Análisis previo
al Diseño del Software
Nivelar conocimientos
adquiridos sobre
análisis de sistemas
Analizar las fases del
diseño del software
Identificar los
procesos y
herramientas para el
diseño orientados a
objetos
Diagramar el software
orientados a objetos.
Actitudes solidarias y
conciencia en la
utilización racional de
los recursos
informáticos.
Actitudes que estimulen
la investigación y la
innovación tecnológica y
científica.
Respeto ante la opinión
ajena.
Unidad didáctica II
Diseño estructurado del
SW
Unidad didáctica III
Fundamentos del Diseño
O.O
Unidad didáctica IV
Diseño de Diagramas
Orientados a Objetos
Ing. Jorge Jaramillo Alba
6
V. PLAN TEMÁTICO
TEMAS C S CP CE T L E THP TI THA
Unidad didáctica I
El proceso del
diseño del SW y su
gestión
10 - 2 - 2 - 2 16 32 48
Unidad didáctica II
Diseño estructurado
del SW
8 - 2 - - 4 2 16 32 48
Unidad didáctica III
Fundamentos del
Diseño O.O
6 - 4 - - 4 2 16 32 48
Unidad didáctica IV
Diseño de
Diagramas
Orientados a
Objetos
- - 4 - - 10 2 16 32 48
TOTAL DE HORAS
24 - 12 - 2 18 8 64 128 192
II. Leyenda:
C – Conferencias.
S – Seminarios.
CP – Clases prácticas.
CE – Clase encuentro.
T – Taller.
L – Laboratorio.
E - Evaluación.
THP – Total de horas presenciales.
TI – Trabajo independiente.
THA – Total de horas de la asignatura.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
7
VI. SISTEMA DE CONTENIDOS POR UNIDADES DIDÁCTICAS
UNIDAD DIDÁCTICA I
EL PROCESO DE ANALISIS PREVIO AL DISEÑO DEL SOFTWARE
Objetivo:
Retroalimentar los procesos previos al diseño de software mediante el repaso de las
etapas del análisis de sistemas que permitan la fundamentación de responsable de las
bases para un buen análisis y diseño de software orientado a objetos.
Tiempo estimado de desarrollo: 16 Horas.
Sistema de conocimientos Sistema de habilidades Sistema de valores
Ámbito del Software
Requisitos del Software
Gestión de proyectos del
Software
Gestión de Riesgos del
Software
Gestión de Calidad del
Software
Gestión de Configuración del
Software
Identificar el proceso
previo al análisis del
software
Determinar las
funciones del software
Determinar la viabilidad
del software
Identificar los riesgos y
contingencias para el
software.
Estructurar el modelo
de calidad del software
Modelar la
configuración para el
desarrollo del software
Actitudes solidarias y
conciencia en la
utilización racional
de los recursos
informáticos.
Responsabilidad en
el planteamiento de
ideas de soluciones
software.
Creatividad en el
modelamiento y
estructuración de los
documentos del
software.
UNIDAD DIDÁCTICA II
ANALISIS Y DISEÑO ESTRUCTURADO DEL SOFTWARE
Objetivo:
o Esquematizar el diseño estructurado del software mediante el estudio de componentes y
procesos relativos al diseño que permitan el aprendizaje perseverante de los componentes
válidos del análisis y diseño orientado a objetos.
Tiempo estimado de desarrollo: 16 Horas
Sistema de conocimientos Sistema de habilidades Sistema de valores
Ing. Jorge Jaramillo Alba
8
El análisis estructurado
Modelado de procesos
Modelado de Datos
El diseño estructurado
Métodos del diseño
Describir el proceso de
análisis estructurado
Establecer los factores
intervinientes en el
modelado de procesos y
datos.
Describir el proceso de
diseño estructurado.
Identificar los métodos
del diseño del software
Actitudes que
estimulen la
investigación y la
innovación tecnológica
y científica.
Actitudes solidarias y
conciencia en la
utilización racional de
los recursos
informáticos.
Honestidad en la
emisión de opiniones
con respecto a los
procesos de análisis y
diseño estructurado
del software.
UNIDAD DIDÁCTICA III
FUNDAMENTOS DEL DISEÑO ORIENTADO A OBJETOS
Objetivo:
Esquematizar procesos mediante la diagramación y representación gráfica de los
elementos del software que permitan la implementación de la creatividad en el diseño.
Tiempo estimado de desarrollo: 16 Horas
Sistema de conocimientos Sistema de habilidades Sistema de valores
El proceso para desarrollo
de Software
Representación gráfica de
los elementos
Diagrama de Casos de Uso
Diagramas de Secuencias
Diagramas de Colaboración
Caracterizar el proceso
de desarrollo del software
Interpretar gráficamente
los elementos del
software
Diagramar casos de uso
del software
Diseñar diagramas de
Secuencia y colaboración
del software.
Actitudes que
estimulen la
investigación y la
innovación
tecnológica y
científica
Actitudes solidarias y
conciencia en la
utilización racional
de los recursos
informáticos.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
9
Creatividad en la
diagramación de
escenarios del
software.
Precisión en la
definición de
escenarios.
UNIDAD DIDÁCTICA IV
DISEÑO DE DIAGRAMAS ORIENTADOS A OBJETOS
Objetivo:
Diagramar procesos del software mediante el uso de herramientas adecuadas que
permitan la obtención puntual de los elementos del diseño del software.
Tiempo estimado de desarrollo: 16 Horas
Sistema de conocimientos Sistema de habilidades Sistema de valores
Diagramas de Clases y
Objetos
Relaciones entre las clases,
Casos particulares de Clase.
Diagramas de Estados
Diagramas de Actividad
Diagramas de Componentes
Interfaces
La interface en el diagrama
de clases y componentes.
Diagramar los procesos
del software
concernientes a Clases y
Objetos.
Relacionar clases.
Diagramar estados,
actividades y
componentes interfaces
del software.
Actitudes que
estimulen la
investigación y la
innovación
tecnológica y
científica
Actitudes solidarias y
conciencia en la
utilización racional
de los recursos
informáticos.
Trabajo Colaborativo
en las tareas de
diseño.
VII. ORIENTACIONES METODOLÓGICAS Y DE ORGANIZACIÓN DE LA
ASIGNATURA.
En cada período de clase se presentará el tema, exponiendo el objetivo
específico y las habilidades que se desea alcanzar.
Ing. Jorge Jaramillo Alba
10
Mediante el autoaprendizaje (exploraciones) se invita a descubrir conceptos y
patrones por su propia cuenta, a menudo aprovechando el poder de la
tecnología.
Se realizaran Actividades en equipo, motivando al estudiante a pensar, hablar y
escribir soluciones en un ambiente de aprendizaje de mutuo apoyo.
Todo estudiante recopilará las investigaciones y ejercicios realizados
debidamente clasificados e indexados como material bibliográfico de apoyo.
Métodos
o Problémico
o Analítico-Sintético
Técnicas activas
o Generación de ideas
o Solución de problemas
o Conferencia participativa
VIII. RECURSOS DIDÁCTICOS
Básicos: marcadores, borrador, pizarra de tiza líquida.
Audiovisuales: Computador, retroproyector, laboratorio de computación.
Técnicos: Documentos de apoyo, Separatas, texto básico, guías de observación,
tesis que reposan en biblioteca.
IX. SISTEMA DE EVALUACIÓN DE LA ASIGNATURA
El sistema de evaluación será sistemático y participativo. Se negociará con los
estudiantes los indicadores de la evaluación colectiva, tanto para ellos como para el
profesor, se tomarán los siguientes indicadores:
Asistencia
Puntualidad
Participación en clases
Trabajo en grupo
La evaluación es un proceso continuo y permanente en lo conceptual, procedimental y
actitudinal, de acuerdo al reglamento se aplicarán diferentes tipos de evaluación:
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
11
o Diagnóstica: establecer el esquema conceptual de partida.
o Formativa: durante el proceso, permite efectuar reajustes a la planificación, y
retroalimentar la información.
o Final: primera aproximación del diseño de investigación, presentación y defensa
ante los compañeros y el docente.
Cabe destacar que también se aplicará autoevaluación, coevaluación y
heteroevaluación. El sistema de evaluación se desarrollará en dos fases:
1. Evaluación del aprendizaje
a. Inicial
b. Procesual
c. Final
2. Acreditación
a. Presentación de un proyecto por escrito.
b. Disertación del proyecto.
X. BIBLIOGRAFÍA BÁSICA Y COMPLEMENTARIA
BÁSICA:
Kendall y Kendall . Análisis y Diseño de Sistemas, 3da Edición, Prentice Hall ,
2002. México.
COMPLEMENTARIA:
Ruble David A. Análisis y Diseño Práctico de Sistemas. 1era Edición, Prentice may,
1998, México.
Hawryszkiewycz I.T . Introducción al Anáñlisis y Diseño de Sistemas con ejemplos
prácticos. 1era Edición, ANAYA, 1988, España.
Ing. Jorge Andrés Jaramillo Alba
DOCENTE
Ing. Jorge Jaramillo Alba
12
ORIENTACIONES PARA EL USO DE LA GUÍA DE ESTUDIOS
I. GENERALIDADES
Antes de empezar con nuestro estudio, debes tomar en cuenta lo siguiente:
1. Tener una actitud positiva, voluntad, motivación e interés.
2. Leer reflexivamente la bibliografía básica, en ella se encuentran todos los temas de
las actividades planteadas.
3. Para aprender cualquier asignatura se necesita tener una fuente de consulta a
mano, por lo tanto se recomienda leer, como mínimo, los textos básicos o guías
expuestos en la bibliografía y reforzar con algunos textos complementarios.
4. Cuando haya hecho esta primera lectura comprensiva, procede a desarrollar las
actividades poniendo en práctica tu actitud crítica y reflexiva, tu capacidad de
síntesis y tu creatividad.
5. Para estudiar debe elegir siempre un lugar tranquilo, cómodo con buena
iluminación, y tener sobre la mesa la bibliografía básica, diccionario, papel. Esfero,
etc.
6. Planifique el tiempo dedicado al sueño y a las comidas, casi todos necesitamos de
8 horas de sueño.
7. Dedique una hora por la mañana que se distribuye para: gimnasia matinal, aseo
personal, vestirse desayunar.
8. Tome en cuenta las horas que son dedicadas a tu trabajo u ocupación personal. Lo
importante es saber determinar el tiempo que necesitas para tus estudios.
9. Es importante que en todo este proceso cultive el valor de la constancia porque no
sirve de nada tener una excelente planificación y un horario si no es constante.
10. Utilice fichas de trabajo o algún cuaderno de resúmenes.
11. Si algún tema o problema no está claro, no dude en llamar o ponerse en contacto
con su profesor guía a fin de solucionar las inquietudes. Favor no quedarse con
éstas porque irán formando lagunas en su aprendizaje que luego son difíciles de
corregir.
12. Para los encuentros con el profesor guía revise la última tarea realizada y a
continuación lea detenidamente las instrucciones dadas en la guía de estudios,
analice y sintetice los temas y conceptos, realice las tareas propuestas.
Para el desarrollo de asignatura se sugiere lo siguiente:
Un cuaderno de apuntes, y al menos un computador Dual Core, 160 GB de
disco duro y memoria RAM de mínimo 1024 MB
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
13
Instaladores de Microsoft Office, herramientas de análisis y diseño de SW
(CASE): Visual Case, Erwin, Microsoft Project.
Lea reflexivamente el texto guía, ahí constan todos los temas a los que
corresponden las actividades planteadas.
Cuando haya realizado ésta lectura comprensiva, proceda a desarrollar las
actividades. No haga una copia textual, sino conteste con sus propias palabras.
Para realizar las actividades, además de la lectura puede ayudarse con la
técnica del subrayado, mapas conceptuales, cuadros sinópticos, etc.
Presente el trabajo desarrollado en computadora con el formato siguiente.
o Papel INEN A4, utilice sangría, márgenes, ortografía
o Margen Superior : 3 cm
o Margen Inferior : 2.5 cm.
o Margen Izquierdo : 3.5 cm.
o Margen Derecho : 2.5 cm.
Incorporamos en esta guía los siguientes gráficos para un mejor desarrollo
Orientaciones de Tarea
Las especificaciones para los trabajos a desarrollar como
parte del proceso de aprendizaje
Resumen:
Sintesis de los temas desarrollados
Nota importante:
Aspectos a los que debes poner atención y que considero
clave para el desarrollo de la asignatura.
DESARROLLO DE ACTIVIDADES
Ing. Jorge Jaramillo Alba
14
Unidad didáctica I: El Proceso de Análisis previo al Diseño
del Software
Introducción: El análisis de sistemas es la ciencia encargada del análisis de sistemas grandes y complejos
y la interacción entre esos sistemas. Esta área se encuentra muy relacionada con la
Investigación de operaciones. También se denomina análisis de sistemas a una de las etapas
de construcción de un sistema informático, que consiste en relevar la información actual y
proponer los rasgos generales de la solución futura.
Los sistemas en relación con el análisis de sistemas están relacionados con cualquier campo
tales como: procesos industriales, administración, toma de decisiones, procesos, protección al
medio ambiente, etc.
En 1953 los hermanos Howard T. Odum y Eugene Odum empezaron a aplicar una visión de
sistemas a la ecología, biológica, basándose en los trabajos de Raymond Lindeman (1942) y
Arthur Tansley (1935).
Los analistas de sistemas utilizan la metodología matemática para obtener los detalles de
los sistemas a los cuales se encuentran analizando, y que a partir de su desarrollo fomentan
el diseño de software.
Objetivo de la unidad didáctica I: Retroalimentar los procesos previos al diseño de software mediante el repaso de las
etapas del análisis de sistemas que permitan la fundamentación de responsable de las
bases para un buen análisis y diseño de software orientado a objetos.
Sistema de contenidos de la unidad didáctica I:
Sistema de conocimientos
Sistema de habilidades Sistema de Valores
Ámbito del Software
Requisitos del Software
Gestión de proyectos del Software
Gestión de Riesgos del Software
Gestión de Calidad del Software
Gestión de Configuración del Software
Identificar el proceso
previo al análisis del software
Determinar las funciones del software
Determinar la viabilidad del software
Identificar los riesgos y contingencias para el software.
Estructurar el modelo
de calidad del software. Modelar la
configuración para el desarrollo del software
Actitudes solidarias y conciencia en la utilización racional de los recursos informáticos.
Responsabilidad en el planteamiento de ideas de soluciones software.
Creatividad en el modelamiento y estructuración de los documentos del software.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
15
Actividades De Aprendizaje Tema I
Desarrollo de contenidos:
El Ámbito del Software
Antes de poder empezar la planificación de un proyecto, deben establecerse el ámbito y los
objetivos, deben considerarse soluciones alternativas y deben identificarse restricciones
técnicas y de gestión. Sin ésta información es imposible obtener estimaciones de costos
razonables y precisas, una identificación realista de las tareas del proyecto o un plan de
trabajo adecuado. El desarrollador de software y el cliente deben ponerse de acuerdo para
definir el ámbito y los objetivos. Los objetivos identificar los fines globales del proyecto sin
considerar como se llegará a esos fines.
El ámbito identifica las funciones primordiales que debe llevar a cabo el software y, lo que es
más importante, intenta limitar esas funciones de manera cuantitativa. El ámbito describe la
función, el rendimiento, las restricciones, las interfaces y la fiabilidad.
Función----------------------* Se evalúan y luego se refinan.
Rendimiento----------------* Requisitos de tiempo de respuesta y procedimiento.
Restricciones---------------* Límites de hardware, memoria, etc.
Interfaces--------------------* Software, hardware, usuarios, procedimientos.
Fiabilidad--------------------* Estimaciones del costo y esfuerzo.
Requisitos del Software
Los requisitos del sistema son La descripción de los servicios y restricciones.
IEEE define “Requisito” como:
Condición o aptitud necesaria para resolver un problema o alcanzar un objetivo.
Condición o facilidad que debe proporcionar un sistema o algunos de sus subsistemas
para satisfacer un contrato, norma, especificación o cualquier otra condición impuesta
formalmente a través de un documento.
Una representación documentada de una condición o facilidad.
Un requisito define: ¿Qué hace el sistema? Y no ¿Cómo lo hace?
Ing. Jorge Jaramillo Alba
16
Especificación de requisitos del software (SRS o ERS). Un documento SRS es la
especificación de las funciones que realiza un determinado producto de software, programa o
conjunto de programas en un determinado entorno.
A través de los SRS se determina qué funcionalidades deben realizarse, qué datos deben
generarse en cada resultado, en qué lugar y quién los debe producir. La SRS debe centrarse
en los servicios que se realizarán, pero, en general, no debe especificar elementos de diseño
o de proyecto. Deben centrarse únicamente en el punto de vista externo del sistema, y no en
el funcionamiento interno.
El documento de especificación de requisitos puede elaborarlo el personal representativo de la
parte suministradora (desarrollador), o de la parte cliente; si bien es aconsejable la
intervención de ambas partes.
Este proceso también es considerado como: elicitación, educción, formulación, identificación o
extracción.
La especificación de requisitos se refiere a la captura y descubrimiento de los
requisitos.
Es una actividad más “humana” que técnica.
Se identifica a los interesados (clientes y usuarios) y se establecen las primeras
relaciones entre ellos y el equipo de desarrollo.
¿A quién (es) se dirigen los requisitos?
El proceso de obtención de requisitos se dirige a:
Usuarios potenciales o clientes
Productores de software o sistemas
Cada uno de estos dos escenarios lleva a situaciones totalmente diferentes: En el primer caso,
se definen las necesidades (puede servir como base para el pliego de condiciones) y será muy
general para permitir distintas soluciones. En el segundo caso, las especificaciones suponen
un paso inicial para el desarrollo de software y deberán ser mucho más específicas.
Técnicas de obtención de los requerimientos
Entrevistas con los actores (clientes y/o usuarios): cerradas / abiertas
Encuestas aplicando cuestionarios con preguntas concretas y respuestas cerradas /
abiertas
Escenarios. Los requisitos se sitúan en el contexto de uso (casos de uso). Permiten
contextualizar y preguntarse sobre ‘¿Qué pasaría si ... ?’ ‘¿Cómo se hace ésto ?’
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
17
Prototipos: permiten clarificar y precisar requerimientos. Útiles cuando la
incertidumbre es total acerca del futuro sistema.
Reuniones de grupo (normales o ‘brainstorming’): permiten aportar mayores puntos de
vista que a través de entrevistas individuales y aflorar puntos de vista contrapuestos.
Es necesario gestionarlas correctamente para evitar conflictos o puntos de vista
dominantes.
Observación de los sistemas actuales y medida de distintos parámetros de los
mismos a través de la inmersión operacional. Ilustra acerca de las tareas y ciertos
procesos complejos o sobreentendidos que raramente se explicitan.
Estudio de los documentos y formularios existentes.
Visitas a otras instalaciones, investigación externa, jornadas profesionales, ferias
Presentaciones comerciales, estudio de productos SW ya existentes.
Clasificación de Requisitos.
La clasificación más típica de los requisitos es la que se presenta a continuación:
Sin embargo, algunos autores presentan otras formas de clasificación de requisitos:
Por prioridades
Por coste de implementación
Por niveles (alto nivel, bajo nivel)
Según su volatilidad/estabilidad
Si son requisitos sobre el proceso o sobre el producto
Requisitos Funcionales:
Definen el comportamiento del sistema.
Describen los servicios o funciones del sistema
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva
generalidad, insuficiencia de detalle o ambigüedad, y el exceso de detalle con
precisiones o descripciones innecesarias o redundantes.
TIPOS DE REQUISITOS
FUNCIONALES Capacidades
Restricciones
NO FUNCIONALES
DE INTERFAZ
Restricciones
Ing. Jorge Jaramillo Alba
18
Requisitos No funcionales: Definen aspectos, que sin ser funcionalidades, (tareas que el
sistema debe realizar) resultan deseables desde el punto de vista del usuario. Generalmente
comprenden atributos de calidad:
Tiempos de respuesta.
Características de usabilidad.
Facilidad de mantenimiento. etc.
Requitos de Interfaz. Definen las interacciones del sistema con su entorno. Interfaces de
Usuarios o con otros sistemas.
ESPECIFICACIÓN DE REQUISITOS.
Para la especificación de los requisitos o documentación es necesario utilizar algún estándar,
así encontramos a los siguientes:
IEEE Std. 830-1998
PSS-05 de la Agencia Espacial Europea (ESA)
El estándar IEEE std. 830 – 1998 contiene la siguiente estructura:
1. Introducción
1.1. Propósito
1.2. Alcance
1.3. Definiciones
1.4. Referencias
1.5. Visión General
2. Descripción General
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Características del usuario
2.4. Restricciones
2.5. Suposiciones
3. Requisitos Específicos
4. Apéndices
5. Índice
Propiedades deseables de los requisitos.
Comprensible por clientes, usuarios y desarrolladores.
Correcto, sin requisitos innecesarios o redundantes.
No ambiguo y con el nivel de precisión necesario.
Completo, que no falten requisitos y que todas las respuestas del sistema a entradas tanto
válidas como inválidas estén especificadas.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
19
Consistente, sin conflictos ni contradicciones entre los requisitos o con documentos de
nivel superior y con una terminología única.
Verificable, que pueda comprobarse que el sistema final cumple los requisitos mediante un
proceso finito y de coste razonable.
Fácilmente modificable, organizada, con los requisitos identificados y con control de
configuración.
Rastreable, de forma que se conozcan las dependencias de los requisitos hacia detrás y
hacia delante.
Priorizada, indicando la importancia de los requisitos.
Anotada con estabilidad, para conocer posibles fuentes de cambios durante el desarrollo.
Independiente del diseño y la implementación, para evitar complejidades innecesarias y no
limitar a los diseñadores.
GESTION DE PROYECTOS DEL SOFTWARE
¿Qué es gestionar? Un concepto general de gestionar es coordinar todos los recursos
disponibles para conseguir determinados objetivos, implica amplias y fuertes interacciones
fundamentalmente entre el entorno, las estructuras, el proceso y los productos que se deseen
obtener.
La gestión de proyectos involucra la planificación, supervisión y control del personal, el
proceso y los eventos que ocurren durante la ejecución del proyecto desde un concepto
preliminar hasta una implementación operativa.
Desde un punto de vista muy general puede considerarse que todo proyecto tiene tres
grandes etapas:
Fase de planificación. Se trata de establecer cómo el equipo de trabajo deberá satisfacer las
restricciones de prestaciones, planificación temporal y coste. Una planificación detallada da
consistencia al proyecto y evita sorpresas que nunca son bien recibidas.
Fase de ejecución. Representa el conjunto de tareas y actividades que suponen la realización
propiamente dicha del proyecto, la ejecución de la obra de que se trate. Responde, ante todo,
a las características técnicas específicas de cada tipo de proyecto y supone poner en juego y
gestionar los recursos en la forma adecuada para desarrollar la obra en cuestión. Cada tipo de
proyecto responde en este punto a su tecnología propia, que es generalmente bien conocida
por los técnicos en la materia.
Fase de entrega o puesta en marcha. Como ya se ha dicho, todo proyecto está destinado a
finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la
puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y
responde a las especificaciones en su momento aprobadas. Esta fase es también muy
importante no sólo por representar la culminación de la operación sino por las dificultades que
suele presentar en la práctica, alargándose excesivamente y provocando retrasos y costes
imprevistos.
Ing. Jorge Jaramillo Alba
20
EL PERSONAL. La formación de personal de software motivado y altamente calificado se ha
debatido desde los años 60. De hecho, el factor humano es considerado como el más
importante en el proyecto, debido a que el desarrollo del software es un trabajo más intelectual
que físico. En los modelos formales como el CMM (Modelo de Madurez de Capacidades),
define en su proceso de gestión de personal, las siguientes áreas: reclutamiento, selección,
gestión del desempeño, entrenamiento, retribución, desarrollo de la carrera, desarrollo de la
organización y el trabajo, y desarrollo de la cultura de equipo.
Los participantes. Se pueden clasificar en 5 categorías:
• Gestores Superiores
• Gestores técnicos del proyecto
• Profesionales
• Clientes
• Usuarios Finales
Los jefes de equipo. Los Jefes de equipo deben poseer ciertas capacidades, así, el modelo
MOI considera las siguientes:
Motivación.- Habilidad para motivar con un <<tira y afloja>>
Organización.- Moldear procesos existentes
Ideas o innovación.- Motivar al personal para crear y sentirse creativos
El equipo de software
La mejor estructura d equipo depende del estilo de gestión de una organización. Mantei,
sugiere tres organigramas de equipos genéricos.
M.M.C.G.P
Reclutamiento
Gestión de rendimiento
Entrenamiento
Retribución Desarrollo cultural
Diseño / organización
Desarrollo
Selección
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
21
“La gestión exitosa de proyectos, independientemente de la estructura organizativa, es sólo
tan buena como lo sean los individuos y líderes que gestionen las funciones básicas”
(Kerzner, 1998)
GESTION DE RIESGOS DEL SOFTWARE
El riesgo. Se halla de forma implícita asociado a toda actividad:
Todo suceso se ve marcado por las acciones del pasado, ¿Se puede, por tanto,
actuar ahora para crear oportunidades en el futuro?
El riesgo acompaña a todo cambio
El riesgo implica elección e incertidumbre.
Estrategias reactivas. Consiste en tomar acciones una vez ocurrido el riesgo. Los métodos
que se pueden aplicar comprenden: la evaluación de las consecuencias del riesgo cuando
este ya se ha producido (ya no es un riesgo) y actuar en consecuencia. Las consecuencias de
una estrategia reactiva pueden ser: apagado de incendios, gabinetes de crisis, se pone el
proyecto en peligro.
Estrategias proactivas. Antes de que ocurra el riesgo, se analizan y se planifican estrategias
de prevención de los riesgos. Como método de prevención se pueden ejecutar las siguientes
actividades: evaluación previa y sistemática de riesgos, evaluación de consecuencias, plan de
evitación y minimalización de consecuencias, plan de contingencias. Algunas posibles
consecuencias son la evasión del riesgo, menor tiempo de reacción, justificación frente a los
superiores.
Riesgo del software. Implica dos características: Incertidumbre (probabilidad de que ocurra)
y pérdida, si el riesgo se convierte en realidad.
Categorías de los riesgos:
Riesgos del proyecto: implica incremento en costes y desbordamiento
organizativo
Riesgos técnicos
DESCENTRALIZADO DEMOCRÁTICO
DESCENTRALIZADO CONTROLADO
CENTRALIZADO CONTROLADO
- No tiene jefe permanente
- Las decisiones se hacen por consensos
- La comunicación entre los miembros es horizontal
- Tiene jefe definido, coordina tareas
- Jefes secundarios, para subtareas
- Comunicación vertical
- El jefe se encarga de la solución de problemas
- La comunicación entre el jefe y los miembros del equipo es vertical.
Ing. Jorge Jaramillo Alba
22
Riesgos del negocio:
De mercado
De estrategia
De ventas
De gestión
De presupuesto
IDENTIFICACIÓN DE RIESGOS. La identificación del riesgo es un intento sistemático para
especificar las amenazas al plan de proyecto (estimaciones, planificación temporal, carga de
recursos, etc.). Existen dos tipos de riesgos para cada categoría presentada anteriormente:
Genéricos: Son comunes a todos los proyectos
Específicos: Implican un conocimiento profundo del proyecto
Calidad: “Conjunto de propiedades y características de un producto o servicio que le confieren
su aptitud para satisfacer unas necesidades explícitas o implícitas”
Control de calidad: “Conjunto de técnicas y actividades de carácter operativo, utilizadas para
verificar los requerimientos relativos a la calidad del producto o servicio”.
Garantía de calidad: “Conjunto de acciones planificadas y sistemáticas necesarias para
proporcionar la confianza adecuada de que un producto o servicio satisfará los requerimientos
dados sobre calidad”.
Gestión de la calidad: “Aspecto de la función de gestión que determina y aplica la política de
la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la
planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la
calidad”.
La gestión de la calidad es responsabilidad de todos los niveles ejecutivos, pero debe estar
guiada por la alta dirección. Su realización involucra a todos los miembros de la organización.
En la gestión de la calidad, se tienen en cuenta también criterios de rentabilidad.
Sistema de gestión de la calidad (QS): “Conjunto de la estructura de la organización, de
responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a
término la gestión de calidad”.
• El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad.
• El QS de una organización está fundamentalmente previsto para satisfacer las
necesidades internas de la organización. Es más amplio que los requerimientos de un
cliente concreto que únicamente valor el QS que le interesa (directamente).
• Para finalidades contractuales o vinculantes en la valoración de la calidad, se puede exigir
que se ponga de manifiesto la realización de ciertos elementos del QS.
La calidad del software
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
23
“La calidad del software es el grado con el que un sistema, componente o proceso cumple los
requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE,
Std. 610-1990).
“Concordancia del software producido con los requerimientos explícitamente establecidos, con
los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos
formalmente, que desea el usuario” (Pressman, 1998)
“Software quality is the degree to which software possesses a desired combination of attributes
(e.g., reliability, interoperability).” (IEEE Std. 1061)
Factores que determinan la calidad del software
Se centran en tres aspectos importantes de un producto software (McCall):
• Características operativas
• Capacidad de soportar los cambios
• Adaptabilidad a nuevos entornos
Satisfacción del usuario
Control de Calidad del Software
• Conjunto de inspecciones, revisiones y pruebas utilizadas a lo largo del ciclo de desarrollo
para asegurar que el producto cumple con los requisitos
• Proceso retroalimentado y de medición
• Proceso manual, automático o semiautomático
Aseguramiento de la calidad de software (SQA)
SQA engloba:
• Un enfoque de gestión de calidad
• Tecnología de Ingeniería de Software efectiva
• Revisiones técnicas formales (RTF) que se aplican durante el proceso del software
• Una estrategia de prueba multiescalada
• Un control de la documentación del software y de los cambios realizados
• Un procedimiento que asegure un ajuste a los estándares de desarrollo de software
• Mecanismos de medición y de generación de informes
Calidad del proceso y del producto
PRODUCTO SATISFACTORIO + BUENA CALIDAD + ENTREGA EN PRESUPUESTO +
ENTREGA EN TIEMPO ESTABLECIDO
SATISFACCIÓN DEL USUARIO =
Ing. Jorge Jaramillo Alba
24
• DEL PROCESO
Atributos de técnicas, herramientas, personal, organización, facilidades
• DEL PRODUCTO
Atributos de documentación de desarrollo y mantenimiento, código, pruebas
Productividad y calidad
• PRODUCTIVIDAD: LDC/mes-persona
• INCREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD
• Mejor calidad, menor trabajo (+/- 50% de ahorro)
• Disminuyen las pruebas
• Localización temprana de errores a menor costo
• DECREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD
• Mejor calidad requiere inversión que se recupera en la entrega
• La revisión de los productos de desarrollo mejora la calidad pero disminuye la
productividad
• Las técnicas de calidad insisten en detalles que pueden constituirse en obstáculos para
el trabajo
PLAN DE GARANTÍA DE LA CALIDAD
Introducción
Propósito
Definiciones, acrónimos y abreviaturas
Referencias
Especificaciones de gestión
Organización
Responsables
Grupo de garantía de la calidad del software
Documentación
Revisión de la gestión
Revisión de los requisitos del software
Revisión de diseño
Revisión del producto
Revisión de operación.
Gestión de configuración
Gestión de problemas y acciones correctivas
GESTION DE LA CONFIGURACION DEL SOFTWARE
Elementos de Configuración del software (ECS)
Al aplicarse el proceso de ingeniería del software se genera una información que se puede
dividir en tres clases:
1. Programas de ordenador (ejecutables y código fuente).
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
25
2. Documentos descriptivos de las aplicaciones (tanto técnicos como de usuario).
3. Datos (datos internos del programa o externos a él).
Todos los elementos que componen la fuente de información producida como resultado del
proceso de ingeniería se conocen como ELEMENTOS DE CONFIGURACIÓN DEL
SOFTWARE.
Proceso de GCS
El proceso de GCS se divide en 5 tareas:
Identificación.
Control de versiones.
Control de cambios.
Auditorias de configuración.
Generación de informes.
Identificación
Se puede tener dos tipos de objetos: objetos básicos y objetos compuestos.
Un objeto básico es una unidad de texto creado por un ingeniero del software durante el
análisis, diseño, codificación o pruebas.
Un objeto compuesto es un grupo de objetos básicos o de otros compuestos.
Cada objeto tiene una colección de atributos que le identifican unívocamente.
Control de versiones
El control de versiones está formado por procedimientos y herramientas para gestionar las
versiones de los objetos de configuración creadas durante el proceso de ingeniería del
software.
Para representar las diferentes versiones se puede utilizar un grafo de evolución o el fondo de
objetos.
Control de cambios
El control de cambios proporciona formas de control humano y herramientas automatizadas
para controlar los mecanismos de control de cambio.
Ing. Jorge Jaramillo Alba
26
Se reconoce la necesidad del cambio
El usuario suscribe la petición del cambio
El desarrollador la evalúa
Se genera un informe de cambios
La autoridad de control de cambios decide
La petición queda pendiente de actuación,
se genera la OCI (orden de cambio de ingeniería)
Petición de cambio denegada
Información al usuarioAsignación personalizada los objetos de configuración
“Dar de baja” objetos (elementos) de configuración
Realización del cambio
Revisión de cambio (auditoría)
Los elementos de configuración que han cambiado son “dados de alta”
Establecimiento de una línea base para la prueba
Realización de actividades de garantía de calidad y de prueba
“Promoción” de los cambios para ser incluidos en la siguiente versión (revisión)
Reconstrucción de la versión adecuada del software
Revisión (auditoría) de los cambios en todos los elementos de configuración.
Cambios incluidos en la nueva versión
Distribución de la nueva versión
Proceso de Control de Cambios
Control de acceso y de sincronización
Alta
Control de
acceso
Baja
Base de datos
del proyecto
Ingeniero
de software
Objeto de configuración
(versión modificada)
Inf. de auditoría Desbloqueo
Objeto de configuración
(versión de línea base)
Info. de pertenencia
Objeto de configuración
(versión extraída)
Bloqueo
Objeto de configuración
(versión de línea base)
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
27
Plan de Gestión de la Configuración
Introducción
Propósito del plan
Alcance
Definiciones y acrónimos
Referencias
Especificaciones de gestión
Organización
Responsabilidades
Actividades de gestión de la configuración
Jerarquía preliminar del producto
Selección de los elementos de configuración
Esquema de identificación de los ecs
Esquema de identificación de versiones y revisiones
Definición de relaciones
Relación de equivalencia
Relación de composición
Definición y establecimiento de líneas base
Definición y establecimiento de bibliotecas de software
Control de cambios
Anexos
Anexo 1: solicitud de cambio
Anexo 2: certificación del cambio
Anexo 3: contabilidad del estado de la configuración
Actividades de auto – evaluación de la unidad I:
¿A quiénes dirigirnos para recolectar requisitos?
¿Qué son los requisitos?
¿Cuál es la clasificación de los requisitos?
Describa las etapas del proceso de la ERS
Investigue las técnicas de especificación de requisitos
¿Cómo se clasifican los requisitos?
Describa el estándar IEEE 830 -1998 para documentar requisitos.
¿Qué actividades comprende el aseguramiento de la calidad de software?
Enumere las actividades de la gestión de la configuración del software
Elabore un resumen mediante un organizador gráfico de calidad y gestión de la
configuración del software.
Orientaciones tarea: A partir de los conocimientos adquiridos resuelva
el siguiente cuestionario.
Ing. Jorge Jaramillo Alba
28
Actividad Final I
Para desarrollar habilidades en la aplicación del proceso de Ingeniería de Requisitos,
verifica si los siguientes requisitos están bien redactados, discútelo con tu profesor guía.
Identifica en cada requisito los siguientes elementos: proceso a automatizar, archivo(s)
lógico(s), los datos a utilizar, y las restricciones u observaciones.
Gestión de Doctores
Req (11) Registrar nuevo doctor, con los siguientes datos: código del doctor, nombre del
doctor, apellido del doctor, especialidad del doctor, estado del doctor, teléfono del doctor,
dirección del doctor.
Req (12) Se permitirá buscar por código o nombres del doctor, pidiendo que ingrese el
dato que desea buscar.
Req (13) Se podrá modificar datos del doctor cumpliendo con el (Req 12) y no se podrá
cambiar el código del doctor. En caso de no constar los datos del doctor en la base de
datos se procederá a cumplir el (Req 11).
Req (14) Genera una consulta que muestre en pantalla un listado de todos los doctores
con sus respectivos datos, previamente cumpliendo con el (Req 12).
Req (15) Dar de baja a los datos de un Doctor, aplicando un criterio de eliminación lógica
por medio del (Req12). Este proceso no implica una eliminación definitiva de la base de
datos.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
29
Unidad didáctica II: El Proceso de Análisis previo al Diseño
del Software
El modelado del software representa las funciones y subfunciones de un Sistema. Los
modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos
pueden incluir notación gráfica, información y comportamiento del Sistema.
Todos los Sistemas basados en computadoras pueden modelarse como transformación de la
información empleando una arquitectura del tipo entrada y salida.
La base para el modelado de análisis del software es la Especificación de los requisitos del
software (ERS).
¿Qué es un modelo?
Un modelo es una simplificación de la realidad
Un modelo es el resultado de un proceso de abstracción y ayuda a comprender y
razonar sobre una realidad
Un modelo de software es una descripción de un aspecto del sistema, expresada en
un lenguaje bien definido.
División del producto
Se fracciona el producto de modo que cada fragmento lo puede realizar un integrante del
equipo de desarrollo.
Ejemplo de un modelo de software
Modelado del Software. Comprende el modelado es el análisis y diseño de aplicaciones
software antes de escribir el código. Se crean un conjunto de modelos (“planos del
software”) que permiten especificar aspectos del sistema como los requisitos, la estructura y
el comportamiento.
Ing. Jorge Jaramillo Alba
30
Utilidad del modelado.
“Una empresa software con éxito es aquella que produce de manera consistente
software de calidad que satisface las necesidades de los usuarios”
“El modelado es la parte esencial de todas las actividades que conducen a la
producción de software de calidad”
Abstracción - Modelado Visual (MV). “El modelado captura las partes esenciales del
sistema”. Parte del proceso de negocio para representar en un modelo visual la solución del
sistema computacional.
Algunas ventajas del modelado visual:
Hay estructuras que no son visibles en los programas.
Ayuda a razonar sobre el cómo se implementa.
Se facilita la comunicación entre el equipo al existir un lenguaje común.
Se dispone de documentación que trasciende al proyecto.
Generación de código a partir de modelos
Ha surgido un nuevo paradigma de desarrollo de software a partir de los modelos
Los modelos:
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
31
visualizan cómo es o queremos que sea el sistema
especifican la estructura y comportamiento del sistema.
guían la construcción del sistema.
documentan las decisiones.
ENFOQUES DE MODELADO DE ANÁLISIS
Existen dos enfoques claramente establecidos:
1. Análisis Estructurado. Comprende actividades como:
Separación datos y procesos
Modelado de Datos
Atributos y relaciones
Modelado de Procesos
Transformación de datos
2. Análisis Orientado a Objetos
Definición de clases
Colaboración entre las clases
ANÁLISIS ESTRUCTURADO
Breve Historia
Es una técnica de modelado del flujo, contenido y transformación de la información que fluye
por un sistema. Nació como complemento al Diseño Estructurado. El término “Análisis
Estructurado” fue popularizado por DeMarco a fines de los 70, quien presentó y denominó los
símbolos gráficos que permitirían al analista crear modelos de flujos de información.
Ing. Jorge Jaramillo Alba
32
Yourdon, Gane y Sarson y otros presentaron variaciones a la propuesta original. A mediados
de los 80, Ward y Mellor proponen ampliaciones para su aplicación en sistemas de tiempo
real y más tarde, Hatley y Pirbhai presentan sus aportes a estos mismos sistemas.
Características
Descomposición / Modularización
Soporte gráfico
Ausencia de Redundancia
Centrado en modelizar el flujo y el contenido de la información PROCESOS y
DATOS
Aproximación TOP-DOWN
Elementos del Modelo de Análisis
Diagramas de Flujo de Datos (DFDs)
Diccionario de Datos (DD)
Diagramas de Entidad-Relación (ER)
Diagramas de Transición de Estado (DTEs)
Especificaciones de procesos (EP), de
Control (EC) y de Datos (ED)
ER
DTE
DFD
DD
ED
EP
EC
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
33
DIAGRAMAS DE FLUJO DE DATOS (DFDS)
Un modelo de proceso es una
manera formal de representar
cómo funciona un negocio
Los DFD son una herramienta
para el modelado de procesos
Es un proceso de modelado TOP-DOWN, es decir se comienza modelando el NIVEL 0 o
CONTEXTUAL, luego se procede con un refinamiento más detallado de sus subprocesos.
Notación:
Ing. Jorge Jaramillo Alba
34
DICCIONARIO DE DATOS DEL DFD. “Es un conjunto de información (datos) sobre datos”, es
decir es un conjunto de metadatos, que ayuda a describir el modelado de Flujos de Datos y
permite organizar de forma común el conocimiento.
Objetivos del DD:
Crear un Glosario de términos
Establecer terminología estándar
Proporcionar referencias cruzadas
Proporcionar control centralizado para cambios
Ejemplo que permite visualizar la Especificación de Procesos vs DFD y DD
El diccionario de datos de los DFD’s se describe en matrices los procesos, almacenes ,
entidades y flujos de datos
- Procesos: Nombre, Descripción, Nivel, Flujos entrantes, flujos salientes
- Flujos de Datos: Nombre, Descripción, Alias (opcional), Origen y Destino
- Almacenes y entidades: Nombre, Descripción, Flujos entrantes, flujos salientes
DIAGRAMA ENTIDAD – RELACIÓN
Se utilizan para definir el modelo de datos
Identifican Objetos y sus Relaciones
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
35
DICCIONARIO DE DATOS DEL DIAGRAMA ENTIDAD RELACIÓN
Entidades: Nombre de entidad, descripción, atributos y descripción de atributos
Relaciones: ID de relación, entidad padre, entidad(es) hija(s), tipo de relación, cardinalidad
HERRAMIENTAS CASE
CASE: Es acrónimo de Computer Aided/Assisted Software/System Engineering. Comprende
un conjunto de herramientas y metodologías que prestan soporte a un enfoque de ingeniería
en el desarrollo de software o en alguna o en todas las fases de este proceso. La tecnología
CASE supone la “informatización de la informática” o “la automatización del desarrollo del
software”.
Objetivos:
Permitir la aplicación práctica de metodologías estructuradas
Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones
Simplificar el mantenimiento de los programas
Mejorar y estandarizar la documentación
Aumentar la portabilidad de las aplicaciones
Facilitar la reutilización de componentes del software
Permitir un desarrollo y un refinamiento visual de las aplicaciones.
Elementos de una herramienta CASE
Repositorio (Diccionario). Donde se almacenan los elementos creados por la
herramienta.
Metamodelo. Marco para la definición de las técnicas y metodologías soportadas por
la herramienta.
Generador de Informes. Herramienta que permite obtener la documentación sobre el
sistema que se está desarrollando.
Ing. Jorge Jaramillo Alba
36
Carga/Descarga de datos. Para intercambiar datos del repositorio con otros sistemas.
Comprobación de errores. Analizar la exactitud, integridad y consistencia de los
esquemas.
Interfaz de usuario. Soporte gráfico para las interacciones del usuario.
Tipos de herramienta CASE
Herramientas de Gestión. Encargadas de la estimación, planificación y seguimiento del
proyecto.
Herramientas Técnica.
CASE Frontales o superiores, que abarcan las primeras fases del análisis y del diseño
CASE dorsales o inferiores, que abarcan el diseño detallado y la generación del código.
Herramientas de Soporte. Como el sistema de repositorio/diccionarios, control y
configuración, seguridad
Ejemplo de algunas herramientas CASE:
Erwing
Visual Case
Easy Case
Power Designer
Weilan L’Case
CASO DE ESTUDIO:
Modelar un Sistema de Información de compra de libros.
El cliente elabora un pedido de libros
La empresa elabora pedidos de libros a los distintos proveedores.
Los proveedores aportan los libros
Se informa a los clientes que sus libros han llegado
Diagrama de Contexto
Se sabe que para la gestión del sistema de pedidos, se realizan las siguientes funciones:
1. Verificación de la validez del pedido del cliente
2. Armar los pedidos a los editores
3. Verificar el envío de los editores
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
37
4. Asignar libros a pedidos
5. Armar entrega a los clientes.
DFD de Nivel 1
Actividades de auto – evaluación de la unidad II:
Amplíe la investigación de los DFD’s y su diccionario de datos.
Profundice la investigación del MER y su diccionario de datos.
Elabore un resumen de las herramientas CASE.
Actividad Final Unidad II
Investigue una herramienta CASE para modelar los DFD’s y el MER.
Orientaciones tarea: A partir de los conocimientos adquiridos resuelva
el siguiente cuestionario.
Ing. Jorge Jaramillo Alba
38
Unidad didáctica III: Fundamentos del diseño Orientado a
Objetos.
EL PROCESO DE DESARROLLO DEL SOFTWARE
Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de
un producto software que reúna los requisitos del cliente. Un producto software en sí es
complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por
pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación
exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas,
valores de variables, datos almacenados, software del sistema, otras aplicaciones que
intervienen, el hardware sobre el cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición
del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos
software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente.
Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto
sino también durante el proceso de desarrollo.
Requisitos nuevos
o modificados
Sistema nuevo
o modificadoProceso de Desarrollo
de Software
Requisitos nuevos
o modificados
Sistema nuevo
o modificadoProceso de Desarrollo
de Software
Figura: proceso de desarrollo de software.
El proceso de desarrollo de software no es único. No existe un proceso de software universal
que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta
diversidad, es difícil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de
actividades fundamentales que se encuentran presentes en todos ellos:
Especificación de software: Se debe definir la funcionalidad y restricciones
operacionales que debe cumplir el software.
Diseño e Implementación: Se diseña y construye el software de acuerdo a la
especificación.
Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el
cliente.
Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
39
Además de estas actividades fundamentales, Pressman menciona un conjunto de “actividades
protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a
continuación:
Seguimiento y control de proyecto de software.
Revisiones técnicas formales.
Garantía de calidad del software.
Gestión de configuración del software.
Preparación y producción de documentos.
Gestión de reutilización.
Mediciones.
Gestión de riesgos.
Pressman caracteriza un proceso de desarrollo de software como se muestra en la Figura. Los
elementos involucrados se describen a continuación:
Un marco común del proceso, definiendo un pequeño número de actividades del marco
de trabajo que son aplicables a todos los proyectos de software, con independencia del
tamaño o complejidad.
Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software,
hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de
calidad, que permiten que las actividades del marco de trabajo se adapten a las
características del proyecto de software y los requisitos del equipo del proyecto.
Las actividades de protección, tales como garantía de calidad del software, gestión de
configuración del software y medición, abarcan el modelo del proceso. Las actividades de
protección son independientes de cualquier actividad del marco de trabajo y aparecen
durante todo el proceso.
Figura: Elementos del proceso del software
Ing. Jorge Jaramillo Alba
40
Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software
es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué,
Cuándo y Cómo debe hacerlo [5].
Figura: Relación entre elementos del proceso del software
En la Figura se muestran los elementos de un proceso de desarrollo de software y sus
relaciones. Así las interrogantes se responden de la siguiente forma:
1. Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más
Roles específicos.
2. Qué: Un Artefacto1 es producido por un Rol en una de sus Actividades. Los Artefactos se
especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de
Artefactos soportando ciertas Notaciones.
3. Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante
el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que
establecen un determinado estado de terminación de ciertos Artefactos.
MODELOS DE PROCESO SOFTWARE
Sommerville define modelo de proceso de software como “Una representación simplificada de
un proceso de software, representada desde una perspectiva específica. Por su naturaleza los
modelos son simplificados, por lo tanto un modelo de procesos del software es una
abstracción de un proceso real.”
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
41
Los modelos genéricos no son descripciones definitivas de procesos de software; sin
embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques
del desarrollo de software.
Modelos que se van a discutir a continuación:
Codificar y corregir
Modelo en cascada
Desarrollo evolutivo
Desarrollo formal de sistemas
Desarrollo basado en reutilización
Desarrollo incremental
Desarrollo en espiral
Codificar y corregir (Code-and-Fix)
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos
pasos:
Escribir código.
Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño,
validación, y mantenimiento.
Este modelo tiene tres problemas principales:
1. Después de un número de correcciones, el código puede tener una muy mala estructura,
hace que los arreglos sean muy costosos.
2. Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del
usuario, por lo que es rechazado o su reconstrucción es muy cara.
3. El código es difícil de reparar por su pobre preparación para probar y modificar.
Modelo en cascada
El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de
ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución y las representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos
con los usuarios del sistema. Se busca hacer esta definición en detalle.
2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se
establece la arquitectura total del sistema. Se identifican y describen las abstracciones
y relaciones de los componentes del sistema.
Ing. Jorge Jaramillo Alba
42
3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de
software. Se realizan pruebas de cada unidad.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en
conjunto. Se entrega el conjunto probado al cliente.
5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto
en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de
implementación. Se identifican nuevos requisitos.
Figura: Modelo de desarrollo en cascada.
Desarrollo evolutivo
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes:
especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta
llegar al producto final.
Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que
las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
Figura: Modelo de desarrollo evolutivo.
Existen dos tipos de desarrollo evolutivo:
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
43
1. Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los
requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se
tiene más claras. El sistema evoluciona conforme se añaden nuevas características
propuestas por el usuario.
2. Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar
para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se
comienza por definir los requisitos que no están claros para el usuario y se utiliza un
prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos
requisitos.
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un
programa ejecutable.
EspecificaciónTranformación
Interactiva
Transformación
Automática
Optimización
Validación de
Especificación
Mantenimiento
Especificación
de alto nivel
(prototipo)
Desarrollo
FormalDesiciones
Especificación
de bajo nivel
Código
Fuente
Especificación
Informal
Figura: Paradigma de programación automática.
Observaciones sobre el desarrollo formal de sistemas:
Permite demostrar la corrección del sistema durante el proceso de transformación. Así,
las pruebas que verifican la correspondencia con la especificación no son necesarias.
Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad
importantes.
Requiere desarrolladores especializados y experimentados en este proceso para
llevarse a cabo.
Desarrollo basado en reutilización
Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo
consta de 4 fases ilustradas en la Figura. A continuación se describe cada fase:
1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el
sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
Ing. Jorge Jaramillo Alba
44
2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con
los componentes de la etapa anterior. Si no se puede realizar modificaciones en los
requisitos, hay que seguir buscando componentes más adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el
sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar
o determinar este marco.
4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran
los componentes y subsistemas. La integración es parte del desarrollo en lugar de una
actividad separada.
Procesos iterativos
A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte
de las iteraciones:
Desarrollo Incremental.
Desarrollo en Espiral.
Desarrollo incremental
Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los
requisitos hasta adquirir experiencia con el sistema. Es una combinación del Modelo de
Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las
decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,
dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un
buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.
Figura: Modelo de desarrollo iterativo incremental.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
45
Desarrollo en espiral
El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue propuesto
por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de
actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso
y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los
riesgos y se elaboran estrategias alternativas dependiendo de estos.
Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo
identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos
dudosos. Se llevan a cabo los pasos para reducir los riesgos.
Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del
riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende
del riesgo identificado para esa fase.
Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del
proyecto.
En la Tabla se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la
selección de un modelo de proceso, la medida utilizada indica el nivel de efectividad del
modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un
nivel de efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos ):
Modelo de
proceso
Funciona
con
requisitos y
arquitectura
no
predefinidos
Produce
software
altamente
fiable
Gestión de
riesgos
Permite
correcciones
sobre la
marcha
Visión del
progreso
por el
Cliente y el
Jefe del
proyecto
Codificar y
corregir
Bajo Bajo Bajo Alto Medio
Cascada
Bajo Alto Bajo Bajo Bajo
Evolutivo
exploratorio
Medio o Alto Medio o Alto Medio Medio o Alto Medio o
Alto
Ing. Jorge Jaramillo Alba
46
Evolutivo
prototipado
Alto Medio Medio Alto Alto
Desarrollo
formal de
sistemas
Bajo Alto Bajo a Medio Bajo Bajo
Desarrollo
orientado a
reutilización
Medio Bajo a Alto Bajo a Medio Alto Alto
Incremental
Bajo Alto Medio Bajo Bajo
Espiral
Alto Alto Alto Medio Medio
Tabla: Comparación entre modelos de proceso de software.
DIAGRAMA DE CASO DE USO (USE-CASE)
Un modelo de casos de uso es descrito en UML como un diagrama de casos de uso
(diagrama use-case) y dicho modelo puede ser dividido en varios diagramas de caso de uso.
Un diagrama de casos de uso contiene elementos de modelo para el sistema, los actores y los
casos de uso y muestra las diferentes relaciones tales como generalización, asociación y
dependencia entre estos elementos. El diagrama de caso de uso debe ser fácil de entender
por el usuario final
Los elementos de un diagrama de casos de uso son:
Sistema
Un sistema en un diagrama de caso de uso es descrito como una caja; el nombre del sistema
aparece arriba o dentro de la caja. Ésta también contiene los símbolos para los casos de uso
del sistema.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
47
Actores
Un actor es alguien o algo que interactúa con el sistema; es quien utiliza el sistema. Por la
frase "interactúa con el sistema" se debe entender que el actor envía a o recibe del sistema
unos mensajes o intercambia información con el sistema. En pocas palabras, el actor lleva a
cabo los casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el
sistema a modelar.
Un actor es un tipo (o sea, una clase), no es una instancia y representa a un rol. Gráficamente
se representa con la figura de "stickman".
Encontrando a los actores de un diagrama de casos de uso.
Es posible obtener a los actores de un diagrama de casos de uso a través de las siguientes
preguntas:
¿Quién utilizará la funcionalidad principal del sistema (actores primarios)?
¿Quién necesitará soporte del sistema para realizar sus actividades diarias?
¿Quién necesitará mantener, administrar y trabajar el sistema (actores secundarios)?
¿Qué dispositivos de hardware necesitará manejar el sistema?
¿Con qué otros sistemas necesitará interactuar el sistema a desarrollar?
¿Quién o qué tiene interés en los resultados (los valores) que el sistema producirá?
Casos de uso
Un caso de uso representa la funcionalidad completa tal y como la percibe un actor. Un caso
de uso en UML es definido como un conjunto de secuencias de acciones que un sistema
ejecuta y que permite un resultado observable de valores para un actor en particular.
Gráficamente se representan con una elipse y tiene las siguientes características:
Un caso de uso siempre es iniciado por un actor.
Un caso de uso provee valores a un actor.
Un caso de uso es completo.
Encontrando casos de uso
El proceso para encontrar casos de uso inicia encontrando al actor o actores previamente
definidos. Por cada actor identificado, hay que realizar las siguientes preguntas:
¿Qué funciones del sistema requiere el actor? ¿Qué necesita hacer el actor?
¿El actor necesita leer, crear, destruir, modificar o almacenar algún tipo de información
en el sistema?
¿El actor debe ser notificado de eventos en el sistema o viceversa? ¿Qué representan
esos eventos en términos de funcionalidad?
Ing. Jorge Jaramillo Alba
48
¿El trabajo diario del actor podría ser simplificado o hecho más eficientemente a través
de nuevas funciones en el sistema? (Comúnmente, acciones actuales del actor que no
estén automatizadas)
Otras preguntas que nos ayudan a encontrar casos de uso pero que no involucran actores
son:
¿Qué entradas/salidas necesita el sistema? ¿De dónde vienen esas entradas o hacia
dónde van las salidas?
¿Cuáles son los mayores problemas de la implementación actual del sistema?
DIAGRAMAS DE SECUENCIA
Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia
temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes
intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el escenario.
En aplicaciones grandes además de los objetos se muestran también los componentes y
casos de uso. El mostrar los componentes tiene sentido ya que se trata de objetos
reutilizables, en cuanto a los casos de uso hay que recordar que se implementan como objetos
cuyo rol es encapsular lo definido en el caso de uso.
Existen dos tipos de mensajes: síncronos y asíncronos. Los mensajes síncronos corresponden
a llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda
bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas
con la cabeza llena. Los mensajes asíncronos terminan inmediatamente, y crean un nuevo hilo
de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua. Los mensajes
se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la
distribución horizontal de los objetos es arbitraria.
El diagrama de secuencias UML muestra la mecánica de la interacción con base en tiempos.
Rol de la Clase
El rol de la clase describe la manera en que un objeto se va a comportar en el contexto. No
se listan los atributos del objeto.
Activación
Los cuadros de activación representan el tiempo que un objeto necesita para completar una
tarea.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
49
Mensajes
Los mensajes son flechas que representan comunicaciones entre objetos. Las medias flechas
representan mensajes asincrónicos. Los mensajes asincrónicos son enviados desde un objeto
que no va a esperar una respuesta del receptor para continuar con sus tareas.
Ing. Jorge Jaramillo Alba
50
Líneas de Vida
Las líneas de vida son verticales y en línea de puntos, ellas indican la presencia del objeto
durante el tiempo.
Destrucción de Objetos
Los objetos pueden ser eliminados tempranamente usando una flecha etiquetada
"<<destruir>>" que apunta a una X.
Loops
Una repetición o loop en un diagrama de secuencias, es representado como un rectángulo. La
condición para abandonar el Loop se coloca en la parte inferior entre corchetes [ ].
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
51
DIAGRAMAS DE COLABORACION
El diagrama de colaboraciones describe las interacciones entre los objetos en términos de
mensajes secuenciados. Los diagramas de colaboración representan una combinación de
información tomada de los diagramas de clases, de secuencias y de casos de uso,
describiendo el comportamiento, tanto de la estructura estática, como de la estructura
dinámica de un sistema.
Rol de la Clase
El rol de la clase describe cómo se comporta un objeto. Los atributos del objeto no se listan.
Rol de las Asociaciones
Los roles de asociación describen cómo se va a comportar una asociación en una situación
particular. Se usan líneas simple etiquetadas con un estereotipo*. (ver al final del documento)
Mensajes
Contrariamente a los diagramas de secuencias, los diagramas de colaboración no tienen una
manera explícita para denotar el tiempo, por lo que entonces numeran a los mensajes en
orden de ejecución. La numeración puede anidarse; por ejemplo, para mensajes anidados al
mensaje número 1: 1.1, 1.2, 1.3, etc. La condición para un mensaje se suele colocar entre
corchetes. Para indicar un loop se usa * después de la numeración.
Ejemplo de Diagrama de Colaboración
Este ejemplo agrega un velocímetro al conjunto de clases que constituyen a un “Avión”. Al
alcanzar una cierta velocidad el velocímetro indicará al timón que debe elevarse y al tren de
aterrizaje que debe retraerse.
Ing. Jorge Jaramillo Alba
52
Actividades de auto – evaluación de la unidad III:
Describa la utilidad y características de cada uno de los elementos que intervienen
dentro de la generación de casos de uso
Describa la utilidad y características de cada uno de los elementos que intervienen
dentro de la generación de diagramas de secuencia
Describa la utilidad y características de cada uno de los elementos que intervienen
dentro de la generación de diagramas de colaboración
Actividad Final Unidad III
A partir de la Actividad Final de la Unidad I realice los casos de uso, diagramas de
secuencia y diagramas de colaboración.
Orientaciones tarea: A partir de los conocimientos adquiridos resuelva
el siguiente cuestionario.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
53
Unidad didáctica IV: DISEÑO DE DIAGRAMAS ORIENTADOS
A OBJETOS
DIAGRAMAS DE CLASES
Los diagramas de clases describen la estructura estática de un sistema. Las cosas que existen
y que nos rodean se agrupan naturalmente en categorías. Una clase es una categoría o grupo
de cosas que tienen atributos (propiedades) y acciones similares. Un ejemplo puede ser la
clase “Aviones” que tiene atributos como el “modelo de avión”, “la cantidad de motores”, “la
velocidad de crucero” y “la capacidad de carga útil”. Entre las acciones de las cosas de esta
clase se encuentran: “acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”.
Un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. Un diagrama
de clases está formado por varios rectángulos de este tipo conectados por líneas que
representan las asociaciones o maneras en que las clases se relacionan entre si.
Clase Abstracta
Las clases se representan con rectángulos divididos en tres áreas: la superior contiene el
nombre de la clase, la central contiene los atributos y la inferior las acciones.
Clase Aviones
En el área superior figura el nombre de la clase que utilizamos como ejemplo, en la central
están sus atributos y en la inferior las acciones que ella realiza. Note que las acciones llevan
paréntesis al final del nombre dado que las mismas son funciones y por lo tanto devuelven un
valor.
Asociaciones
Las asociaciones son las que representan a las relaciones estáticas entre las clases. El
nombre de la asociación va por sobre o por debajo de la línea que la representa. Una flecha
rellena indica la dirección de la relación. Los roles se ubican cerca del final de una asociación.
Los roles representan la manera en que dos clases se ven entre ellas. No es común el colocar
Ing. Jorge Jaramillo Alba
54
ambos nombres, el de la asociación y el de los roles a la vez. Cuando una asociación es
calificada, el símbolo correspondiente se coloca al final de la asociación, contra la clase que
hace de calificador.
Multiplicidad
Las notaciones utilizadas para señalar la multiplicidad se colocan cerca del final de una
asociación. Estos símbolos indican el número de instancias de una clase vinculadas a una de
las instancias de la otra clase. Por ejemplo, una empresa puede tener uno o más empleados,
pero cada empleado trabaja para una sola empresa solamente.
DIAGRAMAS DE OBJETOS
Los Diagramas de Objetos están vinculados con los Diagramas de Clases. Un objeto es una
instancia de una clase, por lo que un diagrama de objetos puede ser visto como una instancia
de un diagrama de clases. Los diagramas de objetos describen la estructura estática de un
sistema en un momento particular y son usados para probar la precisión de los diagramas de
clases.
Nombre de los objetos
Cada objeto es representado como un rectángulo, que contiene el nombre del objeto y su
clase subrayadas y separadas por dos puntos.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
55
Atributos
Como con las clases, los atributos se listan en un área inferior. Sin embargo, los atributos de
los objetos deben tener un valor asignado.
DIAGRAMAS DE ESTADO
En cualquier momento, un objeto se encuentra en un estado particular, la luz está encendida o
apagada, el auto en movimiento o detenido, la persona leyendo o cantando, etc. El diagrama
de estados UML captura esa pequeña realidad.
Estado
El estado representa situaciones durante la vida de un objeto. Se representa con un
rectángulo que tiene sus esquinas redondeadas.
Transición
Una flecha representa el pasaje entre diferentes estados de un objeto. Se etiqueta con el
evento que lo provoca y con la acción resultante.
Ing. Jorge Jaramillo Alba
56
DIAGRAMAS DE ACTIVIDADES
Un diagrama de actividades ilustra la naturaleza dinámica de un sistema mediante el
modelado del flujo ocurrente de actividad en actividad. Una actividad representa una operación
en alguna clase del sistema y que resulta en un cambio en el estado del sistema. Típicamente,
los diagramas de actividad son utilizados para modelar el flujo de trabajo interno de una
operación.
Estados de Acción
Los estados de acción representan las acciones no interrumpidas de los objetos.
Flujo de la Acción
Los flujos de acción, representados con flechas, ilustran las relaciones entre los estados de
acción.
Flujo de Objetos
El flujo de objetos se refiere a la creación y modificación de objetos por parte de actividades.
Una flecha de flujo de objeto, desde una acción a un objeto, significa que la acción está
creando o influyendo sobre dicho objeto. Una flecha de flujo de objeto, desde un objeto a una
acción, indica que el estado de acción utiliza dicho objeto.
Análisis y Diseño Orientado a Objetos
Instituto Tecnológico Superior Ismael Pérez Pazmiño Guía de estudios
57
Estado Inicial
Estado inicial de un estado de acción.
Final State
Estado final de un estado de acción.
Ramificación
Un rombo representa una decisión con caminos alternativos. Las salidas alternativas deben
estar etiquetadas con una condición.
Sincronización
Una barra de sincronización ayuda a ilustrar la ocurrencia de transiciones paralelas, así
quedan representadas las acciones concurrentes.
Diagrama de Componentes Volver
Un diagrama de componentes describe la organización de los componentes físicos de un
sistema.
Ing. Jorge Jaramillo Alba
58
Componente
Un componente es un bloque de construcción física del sistema.
Interface
Una interface describe a un grupo de operaciones usada o creada por componentes.
Dependencias
Las dependencias entre componentes se grafican usando flechas de puntos.
Actividades de auto – evaluación de la unidad I:
Describa la utilidad y características de cada uno de los elementos que intervienen
dentro de la generación de diagramas de clases y de objetos
Describa la utilidad y características de cada uno de los elementos que intervienen
dentro de la generación de diagramas de estado
Describa la utilidad y características de cada uno de los elementos que intervienen
dentro de la generación de diagramas de actividad
Describa la utilidad y características de cada uno de los elementos que intervienen
dentro de la generación de diagramas de componentes
Actividad final Unidad IV:
A partir de la Actividad Final de la Unidad I realice los diagramas de clases, objetos,
estado, actividad y componentes.
Orientaciones tarea: A partir de los conocimientos adquiridos resuelva
el siguiente cuestionario.