g u i a d e e s t u d i o s - intsipp.edu.ec · el estudio de análisis y diseño orientado a...

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


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.



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


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.



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



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


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



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.


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.



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


conciencia en la


de los recursos

informáticos.



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.



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


conciencia en la


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.


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:



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


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



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


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



Sistema de contenidos de la unidad didáctica I:

Sistema de conocimientos

Sistema de habilidades Sistema de Valores

Ámbito 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.



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.


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?


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 ?’



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


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.



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.


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



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.


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



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 =


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).



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.


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


(versión de línea base)

Info. de pertenencia


(versión extraída)

Bloqueo


(versión de línea base)



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.


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.



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.


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:



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.


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



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:


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



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.


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



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.




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.



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


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.”



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.


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:



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.


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.



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


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.



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?


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.



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.


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 [ ].



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.


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


dentro de la generación de diagramas de secuencia


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.





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


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.



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.


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.



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.


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:


dentro de la generación de diagramas de clases y de objetos


dentro de la generación de diagramas de estado


dentro de la generación de diagramas de actividad


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.



g u i a d e e s t u d i o s - intsipp.edu.ec · el estudio de análisis y diseño orientado a...

Documents