Resumen Análisis de Sistemas - Parte 1
Resumen Análisis de Sistemas - Parte 1
Resumen Análisis de Sistemas - Parte 1
ANÁLISISDESISTEMAS
UNIDAD1
9. INSTALACIÓN: Esta es la actividad final, en donde, sus entradas son el manual del
usuario producido en la actividad 7, la base de datos creada en la actividad 8 y el
sistema aceptado por la actividad 6. En algunos casos, la instalación pudiera
significar simplemente un cambio de noche a la mañana al nuevo sistema ; en
otros casos, la instalación puede ser un proceso gradual, en el que
Página 3
Se sabe que el ciclo de vida del proyecto estructurado permite que más de una
actividad se lleve a cabo a la vez. En una situación extrema, TODAS las actividades del
ciclo de vida pudieran estarse realizando simultáneamente. En el otro extremo, el
administrador del proyecto pudiera decidir adoptar el enfoque secuencial, que implica
terminar completamente una actividad antes de emprender la siguiente.
EL ENFOQUE RADICAL del ciclo de vida del proyecto estructurado es aquel en que las
actividades 1 a 9 se llevan a cabo paralelamente desde el principio del proyecto, por
ej. : La codificación se inicia el primer día del proyecto, y la encuesta y el análisis
continúan hasta el último
Dicho esto, ¿qué factores se han de tener en cuenta para determinar el porcentaje de
cada uno?
Si el administrador de proyecto juzga que está tratando con un usuario voluble cuya
personalidad es tal que retrasa la toma de decisiones hasta que el sistema va a
funcionar, entonces probablemente optaría por un enfoque más radical. Por otro lado,
si el administrador trata con un usuario veterano que está absolutamente seguro de lo
que quiere, y si éste último trabaja en un área estable y con poca probabilidad de
cambiar radicalmente de un periodo de tiempo a otro, entonces el administrador
tomará un enfoque más conservador
Otro factor que se debe considerar es la presión a la que se está sometido para
producir resultados tangibles e inmediatos. Si debido a la que se está sometido a las
políticas u otras presiones externas, el equipo que realiza el proyecto debe concluirlo
forzosamente para una fecha determinada, entonces se requiere un enfoque un
enfoque un tanto radical.
Desde luego, todos los proyectos llegan a verse apremiados a llegar a resultados
tangibles donde una de las ventajas de hacer el análisis, diseño, codificación e
implantación del sistema en forma descendente es que se puede suspender una
actividad en cualquier momento y dejar los detalles restantes para consideraciones
posteriores
Página 5
B. EL PROCESO
¿QUÉ ES?
Definimos un proceso de software como un marco de trabajo de las tareas que se
requieren para construir un software de alta calidad
¿QUIÉN LO HACE?
Los ingenieros de software y sus gestiones adoptarán el proceso a sus
necesidades y entonces lo siguen. Además las personas que han solicitado el
software tienen un papel a desempeñar en el proceso de software
Los cinco niveles definidos por el SEI se obtienen como consecuencia de evaluar las
respuestas del cuestionario de evaluación MCM (Modelo de capacidad de madurez)
donde el SEI ha asociado áreas claves del proceso (ACPs) a cada uno de los niveles de
madurez. Las ACPs describen esas funciones de la ingeniería del software que se
deben presentar para satisfacer para una buena práctica a un nivel en particular. Cada
ACP se describe identificando las características sgtes. :
Las ACPs se deberían lograr en cada nivel de madurez del proceso: Nivel 2
Gestión de requisitos
Revisiones periódicas
Coordinación entre grupos
Ingeniería de productos de software
Gestión de integración del software
Programa de formación
Definición del proceso de la organización
Enfoque del proceso de la organización
Para resolver los problemas reales se debe incorporar una estrategia de desarrollo que
acompañe al proceso, métodos y capas de herramientas, y las fases genéricas. Esta
estrategia a menudo se llama MODELO DE PROCESO O PARADIGMA DE INGENIERÍA
DEL SOFTWARE.
Dada la naturaleza recursiva del desarrollo del software, las cuatro etapas tratadas
anteriormente se aplican igualmente al análisis de una aplicación completa y a la
generación de un pequeño segmento de código
Diseño
Generación de código
El diseño se debe traducir en una forma legible por la máquina. El paso de generación
de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la
generación de código se realiza mecánicamente
Pruebas
El proceso de pruebas se centra en los procesos lógicos internos del software, que
asegura que todas las secuencias se han comprobado, y en los procesos externos
funcionales, es decir, realizar las pruebas para la detección de errores y asegurar que
la entrada definida produce resultados reales de acuerdo con los resultados
requeridos
Mantenimiento
Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los
requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta
hacer uso de los fragmentos del programa ya existente o aplica herramientas
MODELO DRA
Se reconoce que el software, al igual que todos los sistemas complejos, evoluciona con
el tiempo. Las estrictas fechas tope del mercado hacen que sea imposible finalizar un
producto completo, por lo que se debe introducir una versión limitada para cumplir la
presión competitiva y de gestión. En esta situación, los ingenieros de software
necesitan un modelo de proceso que se ha diseñado explícitamente para acomodarse
a un producto que evolucione con el tiempo
Características:
Iterativo
Interactivo
Lineal Secuencial
Desarrollan versiones cada vez más completas
- El modelo incremental
- Modelo en espiral
Cada una de las regiones está compuesta por un conjunto de tareas del trabajo,
llamado CONJUNTO DE TAREAS, que se adaptan a las características del proyecto que se
va a emprenderse donde el número de tareas variará dependiendo del tamaño del
proyecto a emprender
Página 16
El modelo en espiral sugiere una actividad del marco del trabajo que aborda la
comunicación con el cliente. El objetivo de esta actividad es mostrar los requisitos del
cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que
se necesita y el cliente proporciona los detalles suficientes para continuar
El primer punto de fijación llamado OBJETIVOS DEL CICLO DE VIDA define un conjunto
de objetivos para cada actividad principal de ingeniería del software. El segundo
punto de fijación llamado ARQUITECTURA DEL CICLO DE VIDA establece los objetivos
que se deben conocer mientras que se definen la arquitectura del software y el
sistema. LA CAPACIDAD OPERATIVA INICIAL es el tercer punto de fijación y representa
un conjunto de objetivos asociados a la preparación del software para la
instalación/distribución, preparación del lugar previamente a la instalación, y a la
asistencia precisa de todas las partes que utilizará o mantendrá el software
Página 17
paradigma T4G puede incluir todas o algunas de las siguientes herramientas: lenguajes
no procedimentales de consulta a base de datos, generación de informes, manejo de
datos, generación de códigos, etc.
Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. El
cliente describe los requisitos, que son, a continuación, traducidos directamente a un
prototipo operativo
Al igual que todos los paradigmas de software, el modelo T4G tiene ventajas e
inconvenientes. Los defensores aducen reducciones drásticas en el tiempo de
desarrollo del software y una mejora significativa en la productividad de la gente que
construye el software. Los detractores aducen que las herramientas actuales de T4G no
son más fáciles de utilizar que los lenguajes de programación, que el código fuente
producido por tales herramientas es “ineficiente” y que el mantenimiento de grandes
sistemas de software desarrollados mediante T4G es cuestionable
- Tecnologías de proceso
Una vez que se ha creado un proceso aceptable se puede utilizar otras herramientas
de tecnología de procesos para asignar, supervisar e incluso controlar todas la tareas
de ingeniería del software definidas como parte del modelo de proceso. Cada uno de
los miembros de un equipo de proyecto de software puede utilizar tales herramientas
para desarrollar una lista de control de tareas de trabajo a realizarse, productos de
trabajo a producirse, y a actividades de garantía de calidad a conducirse
Página 20
El problema del software (en todos sus aspectos) se reduce a la dificultad que
afrontan los desarrolladores para coordinar las múltiples cadenas de trabajo de un
gran proyecto de software. La comunidad de desarrolladores necesita una forma
coordinada de trabajar. Necesita un proceso que integre las múltiples facetas del
desarrollo, donde la presencia de un proceso bien definido y bien gestionado genera
una diferencia esencial entre los proyectos hiper-productivos y los que fracasan. Es
decir, necesitan un método en común, un proceso que:
El Proceso Unificado está basado en COMPONENTES, lo cual quiere decir que el sistema
software en construcción está formado por componentes software interconectados de
interfaces bien definidas
Un sistema software ve la luz para dar servicio a sus usuarios. Por tanto, para
construir un sistema con éxito debemos conocer lo que sus futuros usuarios
necesitan y desean. Esta interacción en un caso de uso.
Página 21
La arquitectura es una viste del diseño completo con las características más importantes
resaltadas, dejando los detalles de lado. Debido a que lo que es significativo depende de
una valoración, que a su vez, se adquiere con la experiencia donde el valor de una
arquitectura depende de las personas que se hayan responsabilizado de su creación. La
arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y
los inversores, y se refleja en los casos de uso. Sin embargo, esta también se ve influida
por muchos otros factores, como la plataforma en la que tiene que funcionar el
software (arquitectura hardware, sistema operativo, sistema de gestión, etc.)
En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes,
crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño
mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si
una iteración cumple con los objetivos el desarrollo continúa con la siguiente iteración. En
caso contrario, los desarrolladores deben revisar sus decisiones previas y probar con un
nuevo enfoque
Página 23
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de
un sistema, como se muestra en la figura. Cada ciclo concluye con una versión del
producto para los clientes
Cada ciclo consta de 4 fases: inicio, elaboración, construcción y transmisión. Cada fase se
subdivide a su vez en iteraciones, como se ha dicho anteriormente
Página 24
- El Producto
Cada ciclo produce una nueva versión del sistema, y cada versión es un producto
terminado preparado para su entrega. Consta de un cuerpo de código fuente incluido en
componentes que pueden compilarse y ejecutarse. Sin embargo, el producto terminado
no sólo debe ajustarse a las necesidades de los usuarios, sino también a las de todos los
interesados, es decir, toda la gente que trabajará con el producto
Aunque los componentes ejecutables sean los artefactos más importantes desde la
perspectiva del usuario, no son suficientes por sí solos. Esto se debe a que el entorno
cambia. A medida que el objetivo del sistema se comprende mejor, los propios
requisitos pueden cambiar. De hecho, el que los requisitos cambien es una de las
constantes del desarrollo de software. Para llevar a cabo el siguiente ciclo de manera
eficiente, los desarrolladores necesitan todas las representaciones del producto
software
Página 25
Un modelo de casos de uso, con todos los casos de uso y su relación con los
usuarios
Un modelo de análisis, con dos propósitos: refinar los casos de uso con más
detalle y establecer la asignación inicial de funcionalidad del sistema a un
conjunto de objetos que proporciona el comportamiento
Un modelo de diseño que define: (a) la estructura estática del sistema en la forma
de subsistemas, clases e interfaces y (b) los casos de uso reflejados como
colaboraciones entre los subsistemas, clases, e interfaces
Un modelo de implementación que incluye componentes (que representan al
código fuente) y la correspondencia de las clases con los componentes
Un modelo de despliegue, que define los nodos físicos (ordenadores) y la
correspondencia de los componentes con esos nodos
Un modelo de prueba, que describe los casos de prueba que verifican los casos
de uso
Una representación de la arquitectura
ESTRATEGIAS
Esta se defina como un plan para lograr un objetivo. Las estrategias afectan a aspectos
como la arquitectura del sistema, el orden en que se llevaran a cabo las actividades del
proceso y las metodologías a utilizarse. Dada la variedad de probabilidades, es necesario
tomar ciertas decisiones iniciales correspondientes a tipo de proyecto a desarrollase.
Estas decisiones son parte de una estrategia de desarrollo, la cual incluye la selección de
una tecnología y lenguaje de programación particular. Otras estrategias aceptadas en la
actualidad son los prototipos y la reutilización.
PROTOTIPOS
REUTILIZACIÓN
HERRAMIENTAS
UNIDAD II USUARIOS
Página 29
Obviamente, en situaciones de este tipo, hay una gran posibilidad de males entendidos; lo que
le usuario quiere que el sistema haga pudiera no serle comunicado de manera correcta al
analista, y lo que este crea que está construyendo para el usuario pudiera no serle comunicado
tampoco de manera correcta, hasta que ya se hubiera terminad, cuando ya sería demasiado
tarde. De esto se pueden sacar 2 conclusiones importantes:
- Siempre que sea posible, el analista debiera tratar de establecer contacto directo
con el usuario. Aun si se encuentran involucradas otras personas como
intermediarios
Uno de los errores más frecuentes que cometen en el campo de las computadoras sobre todo
los programadores y a veces también hay analistas, es suponer que todos los usuarios son
iguales. Aún cuando sea obvio deberá intervenir más de un usuario, se tiene la tendencia a
pensar en ellos como un grupo de humanos amorfo y homogéneo
Decir simplemente que un usuario difiere de otro es insuficiente. Por lo que aquí hay dos
maneras de clasificar a los usuarios:
LOS USUARIOS OPERACIONALES son oficinistas, administradores y operadores que son los
que probablemente tendrán contacto diario con el nuevo sistema (a menos que esté
Página 30
construyendo un sistema de apoyo a las decisiones, en cuyo caso tendrá poco contacto con
este grupo). Se debe tener tres cosas en mente cuando se trabaja con usuarios de nivel
operacional:
1. Los usuarios de este nivel se preocupan mucho por las funciones que tendrá el
sistema, pero es más probable aún que se preocupe por los detalles de la interfaz
humana. Esto significa que, como analista, necesitará tener comunicación directa
con el usuario operacional o, estar muy seguro de que la persona que representa a
éste tenga presente tales detalles
Muchos de ellos son usuarios operacionales que han sido promovidos. Por eso,
están familiarizados con el trabajo de los subordinados operacionales y se puede
suponer que estarán de acuerdo con sus necesidades, preocupaciones y
perspectivas
También, a menudo se interesa en un nuevo sistema de información por la
posibilidad de incrementar el volumen de trabajo realizado disminuyendo a la vez el
costo de procesar transacciones y reduciendo también los errores en el trabajo
Por lo general, el usuario supervisor es el que ve al nuevo sistema como una forma
de reducir el número de usuarios operacionales o de evitar que aumente se número al
crecer el volumen de trabajo
Página 31
Pueden proporcionar la iniciativa del proyecto, pero es más probable que sirvan
como autoridad para financiar las solicitudes que se originan en niveles más bajos
de la organización
Los usuarios ejecutivos se preocupan más por los detalles estratégicos y las
ganancias/pérdidas a largo plazo. De aquí que, por lo regular, estén menos
interesados en asuntos operacionales
Los usuarios de nivel ejecutivo se interesan más en el panorama global del sistema,
por lo que suelen no interesarse por los detalles. Por lo que el analista deberá utilizar
las herramientas de modelado que permiten dar un panorama global de sistemas
Similarmente, los usuarios ejecutivos por lo general pueden trabajar con modelos
abstractos de un sistema
EL AMATEUR es aquél que jamás ha visto una computadora y que exclama a todo pulmón y
con frecuencia que él “no entiende todo este asunto de las computadoras”. Esto presenta
un reto para el análisis de sistemas al que le encanta hablar del “acceso de línea” y los
“diálogos hombre-máquina dirigidos por menús” y terminologías por el estilo. Pero si el
analista hace bien su trabajo, no hay razón por la cual el usuario deba interesarse por las
computadoras o tener grandes cono conocimientos acerca de ellas.
En realidad, el verdadero problema con el usuario amateur es un tanto más sutil: puede
ser que encuentre difícil de entender el “lenguaje” que el analista usa para describir las
características, funciones y opciones que ofrece el sistema que se va a implantar
Desde luego, hay algunos usuarios que realmente entienden el análisis de sistemas, y también
la tecnología de computadoras. Es un placer trabajar con tales personas; de hecho, el único
problema pudiera ser que el usuario y el analista obtengan tal placer de la discusión sobre
herramientas y técnicas de análisis, que se olviden por completo de que verdadero objetivo es
implantar un sistema
ADMINISTRACIÓN
- Cuanto más alto nivel ocupen menos probable es que sepan de la tecnología de las
computadoras.
- También es cómodo suponer que una vez que la administración toma una decisión
colectiva acerca de un determinado proyecto se atiene a dicha decisión. Sin
embargo, no necesariamente sucede así: pudiera ser que fuerzas externas obliguen
a la administración a acelerar determinado proyecto, a quitarle recursos o, de plano
abandonarlo
Página 34
EL ANALISTA DE SISTEMAS.
- Innovador: El analista debe distinguir entre síntomas, problemas del usuario y causas:
con sus conocimientos el analista debe ayudar al usuario a explorar aplicaciones
novedosas y más útiles de las computadoras así como nuevas formas de hacer
negocios.
El diseñador de sistemas es el que recibe los resultados del trabajo de análisis realizado
por el analista. Su labor es transformar la petición, libre de consideraciones de
tecnología, que surge de los requerimientos del usuario, en un diseño arquitectónico de
alto nivel que servirá de base para el trabajo de los programadores.
PROGRAMADORES.
El trabajo de programador suele comenzar cuando termina el trabajo del analista. Son
aquellos que "accionan" el sistema desarrollado por el analista y el diseñador en
conjunto con el usuario.
Su contacto con el usuario es reducido, el cual sólo surge cuando el mismo requiere
especificaciones de bajo nivel, las cuales el analista no suele describir de manera
detallada.
PERSONAL DE OPERACIONES
ENTREVISTAS UNIDAD 3
quienes responden
Los objetivos son información importante que puede ser recogida de las entrevistas. Los
hechos que se obtienen de los datos relevantes pueden explicar el desempeño pasado,
Página 36
pero
comolos
seaobjetivos
posible aproyectan el futuro
partir de las de la organización. Trate de encontrar tanto objetivos
entrevistas
PLANEACIÓN DE LA ENTREVISTA
decisiones acerca de las cuales querrá hacer preguntas. Estas áreas incluyen:
a. Fuentes de información
b. Frecuencia de la toma de decisiones
c. Cualidades de la información
d. Estilo de la toma de decisiones
3. PREPARE AL ENTREVISTADO: Prepare a la persona a ser entrevistada, llamándole
con anticipación y permitiendo que el entrevistado tenga tiempo para pensar
acerca de la entrevista. Acomode tiempo para llamadas telefónicas y reuniones. Las
básicas que es necesario saber. Los dos tipo de preguntas son abiertas y cerradas
Tipos de preguntas
PREGUNTAS ABIERTAS
“Abierta” describe, de hecho, las opciones del entrevistado para responder. La respuesta
pueden ser 2 o más palabras o párrafos. Los beneficios de usar preguntas abiertas son:
Pone confortable al entrevistado
Proporciona riqueza de detalles
Revela cambios para preguntas posteriores que podrían haber quedado sin atacar
PREGUNTAS CERRADAS
Las preguntas cerradas, que tienen la forma básica “¿Qué tantos subordinados tienen? Las
respuestas están cerradas al entrevistado, debido a que solamente puede responder con
un número finito, donde estas limitan las respuestas disponibles del entrevistado
Sin embargo, las desventajas del uso de preguntas cerradas son sustanciales. Incluyen:
Ser aburridas para el entrevistado
No llegan a obtener grandes detalles
Se pierde ideal principales por la razón anterior
No se llega a establecer una relación armoniosa entre el entrevistado y el
entrevistador
AVERIGUACIONES.
es la más simple ¿PorUn qué?
tercer tipo de pregunta es la “averiguación”. La averiguación más fuerte
El objetivo
para de la
aclararlo averiguación
y para obtener es ir más allá de la respuesta inicial para obtener más significado,
pueden ser preguntas abiertasy oexpandir
cerradasel punto de vista del entrevistado. Las averiguaciones
Si se hace
signo en se
de que unaestá
forma sistemática
escuchando y determinada,
lodonde
que seen
está la averiguación
diciendo, pensándoloserá reconocida como
cuidadosamente y un
respondiendo
investigador”, adecuadamente,
deberá averiguar en
en una forma vez
quedeexhiba
usar un
su enfoque
interés y“reportero-
deseo de comprender
las respuestas del entrevistado
FALLAS ENpregunta
cualquier LAS PREGUNTAS. Redactando sus preguntas de antemano será capaz de corregir
pueden arruinar lostonta
datosque haya escrito. Busque tipos de preguntas problemáticas que
Página 38
Elusión deque
respuesta preguntas
unotipo conducentes:
parece querer. LaEstas tienden
respuesta es aentonces
dirigir alsugerida,
entrevistado hacia
debido la
a que
está poniendo un de trampa
Elusión
que de preguntas
de hecho dobles:
son dosque Son separadas.
preguntas aquellas enUna
las que se usa doble
problema una sola pregunta
es una para lo
alternativa
propósito odebido
no) o sea puede
el entrevistado
caer en errorpuede responder
sobre el solamente
cual pregunta unamala
pregunta y(a
está respondiendo
sacar una conclusión equivocada
ACOMODO DE LAS PREGUNTAS EN UNA SECUENCIA LOGICA. Así como hay dos formas
reconocidas generalmente para razonar: inductiva y deductiva, hay dos formas similares
para una situación particular. Aunque se decida seguir la ruta no estructurada, de todas
Página 39
formas
Para el deberá
enfoqueestar preparado para
no estructurado la entrevista tal como se dijo en los
quepasos anteriores.
preguntas redactadas precisamentesugerimos al en
en la forma menos un breve
que serán guión
preguntadas incluya muchas
Registro de la entrevista
Se realiza sobre los aspectos más importantes de la entrevista. El que se tomen notas o se
use una grabadora de cinta depende, en parte, de a quién se está entrevistando y de lo que
se hará con la información una vez que haya pasado la entrevista.
Grabadora de cinta: Tiene como ventajas que el registro es exacto, libera al
entrevistador para escuchar y responder más rápidamente, permite mejor
contacto visual, y permite una reproducción exacta de la entrevista para otros
miembros del equipo. Tiene como desventajas que hace posiblemente inquietante
la entrevista, la dificultad de buscar diálogos determinados en la cinta, y el
relevamiento de datos.
Toma de Notas: Se utiliza cuando el entrevistado se rehúsa a la petición de la
grabación en cinta. Tiene como ventajas que mantiene alerta al entrevistador,
ayuda a recordar preguntas importantes, demuestra preparación e interés del
entrevistador. Como desventajas, tenemos la pérdida de contacto visual y del hilo
de la entrevista.
El líder de la sesión
comunicación debe serlas
para facilitar alguien que tenga
interacciones habilidades excelentes de
adecuadas.
1 o 2 observadores
funcionales que sean analistas
para proporcionar o expertos
explicaciones técnicos
técnicas de otras
y consejos áreas
al grupo.
Un escribano
escribano para escribir
publique formalmente
el registro todo lo de
de los resultados queJAD
se rápidamente.
hace. Asegúrese que el
proyecto.
retroalimentación seriamente
participantes
Página 42
2. Cuando la ypreparación
seguimiento de las sesiones
la documentación JAD es inadecuada o cuando el reporte de
esnecesarias
incompleta
3. Las habilidades
desarrolladas lo organizacionales
suficiente para el esfuerzo y la cultura
concertado queorganizacional pueden
se requiere para no estar en
ser productivo
un ambiente JAD
CUESTIONARIOS
impida la selección
de personas, debidodea la
cualquier
cantidadotra. Se deben
de datos que usar para investigar a una gran muestra
se obtendrán.
Cabe desatacar
aprecian losdel que es muy importante la selección de palabras, ya que los interlocutores
esfuerzos
propio uso lenguaje.de alguien que se preocupa por escribir un cuestionario que refleje su
Para confirmar si el lenguaje usado es el adecuado, puede probarlo sobre un grupo piloto. Uso
de Escalas
El
conescalamiento
objeto es el proceso de asignar números Las
u otros símbolos a un atributo o arbitrarias
característica
pueden no de
sermedir
únicas.ese
Seatributo o característica.
utilizan escalas para: escalas son frecuentemente y
2- Tendencia
creando Central: Lospuntos,
interlocutores califican todo como
etc. promedio. Se puede arreglar
3- Efectoescalas
siguiente de con
halo:
pregunta
más
Cuando achicando
la impresión diferencias,
formada en una pregunta se transporta a la
desechados.
Existen 4 formas de administrar el cuestionario:
1- Reunir a todos los interlocutores involucrados a la vez: No hay tiempo de espera y no se
pierden cuestionarios. Sin embargo, tiene como desventaja la presión del grupo
2- Manejar personalmente cuestionarios en blanco y recoger los llenos: Requiere mucho
tiempo y suele haber escepticismo en las respuestas.
3- Permitir a los interlocutores que administren el cuestionario por sí mismos y los
depositen
en una caja: Tiene como ventaja que las personas se sienten en el anonimato, pero sin
embargo pueden perderse cuestionarios
4- Enviar por correo los cuestionarios, con instrucciones para el retorno: Tiene muy baja
tasa de respuesta
OBSERVACIÓN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL AMBIENTE DE
OFICINA
El analista examina
influencia los elementos físicos del espacio de trabajo del tomador para ver su
elementos sobre
físicosel comportamiento
sobre del mismo.
los que el tomador Además,
de decisiones mediante
tiene control,laelobservación de los
analista puede
Página 45
determinar el mensaje
provoca sobre que
las demás está enviando
personas este tomador de decisiones, y la influencia que
de la organización.
-aleatoriedad
Elimina la tendencia
de con la -comportamientos
Permite la observación de
conforme
observaciones
-representativa
Permite una vista suceden
-un
Permite laconsiderado
observación de
de
actividades frecuentes evento
importante
Ventajas
-fragmentada
Recolecta datos
que en
no forma
da -tiempo
Se lleva gran
del cantidad de
analista
tiempo
para que se desarrolle una
decisión
- Se pierde una muestra
Desventajas - Se pierden decisiones
representativa de
importantes
poco frecuentes decisiones
frecuentes
hechos dichos por los miembros de la organización, contra lo que dice el tomador
Página 47
de decisiones.en
Según se confirme/niegue/invierta lo que seaveriguar
dijo, se coloca un símbolo
4- determinado
Comparación
examina el delalacaracterística
ambiente y se compara
y se determina
observación/narrativa:
con las Es si
elsemétodo
debe
narraciones, y menos más.
mediante estructurado.
el resultado de Se
la
comparación se determina el investigar más o no.
MUESTREO
El muestreo es el proceso de seleccionar sistemáticamente elementos representativos de
una población. Cuando estos elementos seleccionados son examinados de cerca, se supone
que el análisis revelará información útil acerca de la población como un todo.
El analista de sistemas tiene que tomar una decisión sobre 2 puntos. Primero, hay muchos
reportes, formas, documentos, que han sido generados por los miembros de la
organización ¿A cuáles de éstos debe prestar atención el analista de sistemas y cuáles debe
ignorar? Segundo, gran cantidad de empleados pueden ser afectados por el sistema de
La reducción de la ascendencia
Muestreo
lista Sistemático:
de empleados de laEj.: Elegir entrevistar a cada enésima persona de una
compañía
Muestreo Estratificado
Muestreo Aglomerado:
4- Decidir el tamaño de la muestra: El tamaño de la muestra depende frecuentemente del
costo involucrado en el tiempo requerido por el analista de sistemas, o hasta el tiempo
datos archivados.
Ventajas del uso de datos
archivados
Desventajas del uso de datos archivados
Ya fueron pagados por alguien más Existe incertidumbre sobre si los datos son un
Página 49
Los
que datos no sonno
el productor cambiados, debidodea
está consciente
que está siendo estudiado subconjunto de los datos originales
Los registros que sobreviven pueden no ser los
más importantes
Pueden tener ascendencias, ya que alguien
decidió originalmente lo que había que
archivar
Es difícil obtener nuevos datos de muestras
equivalentes
UNPROCESODIRIGIDOPORCASOSDEUSO
El objetivo del
distribución Proceso
eficiente deUnificado
sistemas es
queguiar a los desarrolladores
se ajusten a las necesidadesen la
deimplementación
los clientes.no y
El es
paso
desde la determinación
En primer lugar, debede las necesidades
se comunicarse
encontrar del cliente
algún modo hastalas
de capturar la necesidades
implementación del usuario trivial.
de
forma que
Después, puedan
debemos ser capaces fácilmente a todas
de diseñarmediante las personas
una implementación implicadas en
funcionalDebido el proyecto.
que se aajuste a las
necesidades
complejidad, del
el cliente
proceso se
sehan cumplido
describe como una serie pruebas
de del
flujos de sistema.
trabajo que esta
construyen el
sistema gradualmente
Fig. El Proceso
consiste en unaUnificado
serie de
flujos
desde de
lostrabajo quehasta
requisitos van
las pruebas.
trabajo Los flujos
desarrollan de
modelos,
de casos desde
de uso el modelo
hasta el
modelo de prueba
Los
uso desarrolladores
ende
eluso,
modelo decomienzan
casos capturando
de uso. Después los requisitos
analizan del cliente
yanálisis,
diseñan en lapara
el sistema forma de casos
cumplir los de
casos creando
implementación, enincluye
el cual primer lugar
todo elun modelo
código, es de
decir, después
los componentes.uno de diseño,
Porelúltimo,otro
los de
desarrolladores preparan un modelo de prueba que les
proporciona la funcionalidad descrita en los casos de uso permite verificar que sistema
¿Por qué casos de uso?
Página 50
Para
de capturar
uso permite los requisitos que aportan valor que
añadido: En los
primer lugar,del
la idea de caso
casos de
usuarios. uso sonlalas
Tomando
identificación
lafunciones
del proporciona
que
perspectiva
software uncumple
sistema objetivos
para añadir usuario.
valor alos Los
suscasos
de uso que necesitan para hacer sudetrabajo
cada tipo de usuario, podemos capturar
Los mejores casos de uso son aquellos que añaden valor al negocio que implanta el
sistema. Un caso de uso que aporta un valor negativo o que permite hacer al usuario
ellas
Para idear la arquitectura y más…: Los casos de uso nos ayudan a llevar a cabo el
desarrollo. En otras palabras, en cada iteración se identifican e implementan unos
cuantos casos de uso. Mediante la selección del conjunto correcto de casos de uso
para llevarlos a cabo durante las primeras iteraciones, podemos implementar un
sistema con una arquitectura estable, que pueda utilizarse en muchos ciclos de
desarrollo subsiguientes. Los casos de uso también se utilizan como punto de partida
para escribir el manual de usuario. Ya que cada caso de uso describe una forma de
utilizar el sistema, son el punto de partida ideal para explicar cómo puede el usuario
LACAPTURADECASOSDEUSO
El modelosobre
acuerdo de casos
cómode uso ayuda al cliente, a los usuarios y a los desarrolladores a tipos
llegarde
a un
usuarios
sistema donde
al cada utilizar
interactuartipo
con de el
los
sistema.
usuario
casos de
La mayoría
seuso.
representa
Todos
de los sistemas
mediante
los actores un
y
tienenestos
ACTOR,
casos de
muchos
uso utilizan
del sistemael
forman un
modelo de modelo
casos dede
usocasos de uso.un
y muestra Unconjunto
diagramadedecasos
casosdedeuso
usoy describe parte
actores con delasociación
una modelo de
entre cada par actor/caso de uso que interactúan
No todos los actores representan a personas. Pueden ser actores otros sistemas o
hardware externo que interactuará con el sistema. Cada actor asume un conjunto
coherente de papeles cuando interactúa con el sistema. Un usuario físico puede actuar
como uno o varios actores, desempeñando los papeles de esos actores en su intersección
con el sistema. Vario usuarios concretos pueden actuar como ocurrencias del mismo actor.
Los actores se comunican con el sistema mediante el envío y recepción de mensajes hacia
y desde el sistema según éste lleva a cabo los casos de uso. A medida que definimos que
hacen los actores y lo que hacen los casos de uso, se trazará una clara separación entre las
responsabilidades de los actores y las del sistema. Esta separación nos ayuda a delimitar el
concreto”
Cada uno de los diferentes modos de utilizar el sistema que añaden valor al usuario es un
caso de uso candidato. Estos candidatos se ampliarán, se cambiarán, se dividirán en casos
de uso más pequeños, o se integrarán en casos de uso más completos. El modelo de casos
de uso recoge todos los requisitos que pueden comprender los clientes, usuarios y
Página 52
desarrolladores.
es un camino de La secuencia
específico de del
a través acciones realizada
caso de uso. por un
Puede casomuchos
haber de uso caminos,
durante su operación
ser variantes
hacer que un la ejecución
modelo de dede
casos la uso
secuencia
sea de acciones
comprensible, especificadas
podemos agrupar casoestos pueden
en eldescripciones
de uso. Para
de
caminos variantes parecidas en un solo caso de uso
Los
comocasos de uso también
losderequisitos se utilizan como
de rendimiento, “contenedores”
disponibilidad, deylos
exactitud requisitos
seguridad quenoson
funcionales, tales
específicos de
un caso uso.
CAPTURADEREQUISITOSCOMOCASOSDEUSO
El esfuerzoy principal
construir, en ladefase de de
requisitos es desarrollar un modelo del ese
sistema que Esto
se vaesa
debido quelalos
que laamayoría
yy pueden
utilización
requisitos casos
funcionalesuso en
seno una formadeadecuada
estructuran forma de crear
natural mediante modelo.
un solocasos de uso,
tratarsede enlos otros
el contextorequisitos
de ese caso funcionales
de uso son específicos de caso de uso,
Los casos decon
funcionales usoun
proporcionan un medio
énfasis especial intuitivo
en el de
valor y sistemático para capturar los requisitos
sistema
pensar externo.
en Mediante
términos la utilización
de quiénes son los losañadido
usuarios casos
y quéde para
uso,cada
necesidades
usuario
los analistas
ude
individual
se ven
objetivos
o para acada
deobligados
la empresa
pueden
motivo importante para su aceptación en la mayoría de los métodos de la ingeniería sido
cumplir. Su papel clave en la dirección del resto del trabajo desarrollo ha un
moderna
de software
Vamos a describir
Los artefactos el flujo
creados en de trabajo
el flujo de los requisitos
de trabajo en 3 pasos: 1-
de los requisitos
2- Los trabajadores participantes en el flujo de trabajo de los requisitos
ARTEFACTOS
lleguen a un acuerdo sobre los requisitos, es decir, sobre las condiciones y posibilidades
Página 53
ARTEFACTO: ACTOR
Un actor es una idealización de una persona externa, de un proceso, o de una cosa que
interactúa con un sistema, un subsistema, o una clase. Un actor caracteriza las
interacciones que los usuarios pueden tener con el sistema. Diferentes usuarios pueden
estar ligados al mismo actor y por lo tanto pueden representar casos múltiples de la
En el modelo, la ejecución
implementación deuso
de casos de cada paso crear
puede es independiente deimplícitas
dependencias las demás, aunque
entre ellas,una
debido a los
objetos compartidos
Aunque
puede cada instancia de un casodedeotros
uso es independiente, la descripciónesdesimilar
un caso de uso se
en quedescomponer
la descripción
descripción de las
en
defactores
una clase
superclases. Un se puede
caso de
casos
uso
de uso
definir
puede
más simples.
incrementalmente
incorporar
Esto
a partir
simplemente de laa la manera
el
comportamiento
se deDE
otros casos de En
usoeste
como fragmentos de sude
propio comportamiento. Esto
delllama RELACIÓN
caso de INCLUSIÓN.
uso original, y no se puede caso,
sustituir el nuevo
por él caso uso no es un caso especial
Un caso
base. de uso
ESTO se puede tambiénDEdefinir como una extensión incremental de un caso de uso
caso de
agregan uso,SEque
LLAMA RELACIÓN
pueden EXTENSIÓN.
ser aplicadas Puede
conjuntamente. haber varias extensiones
Las extensiones delbase
a un caso mismo
se
extensióna su semántica; que es el caso de uso base instanciado, no los casos de uso de la
TRABAJADORES Y RESPONSABILIDADES
Página 55
FLUJO DE TRABAJO
El diagrama utiliza calles para mostrar que trabajadores ejecutan qué actividades; cada
actividad (representada por ruedas dentadas) se sitúa en el mismo campo que el
trabajador la ejecuta. Cuando los trabajadores ejecutan las actividades, crean y modifican
artefactos. Describimos los flujos de trabajo como una secuencia de actividades que están
ordenadas, así que una actividad produce una salida que sirve de entrada para la próxima
de uso)
Esta actividad consta de 4 pasos:
Encontrar los actores
Encontrar los casos de uso
Describir brevemente cada caso de uso
En ambosycasos,
externos debemos
los actores paraidentificar los actores
el mantenimiento identificardel
y operación lossistema
actores que representan sistemas
Hay dos criterios
identificar al menosútiles
a aunalos
la hora de
usuario queelegir
pueda losrepresentar
candidatosala actor
actores: 1ro., debería
candidato. ser posible
encontrar
en nuestrasolamente
imaginación. actores
2dode relevantes,
, debería y eliminará
existir actores
una a los
coincidencia actores
mínima queEsto
entre sólo
los
nos
sonayudará
roles
a
fantasmas
que
desempeñan las instancias los diferentes
dos o más actores que en esencia tengan los mismos roles en relación con el sistema. No queremos
Página 57
un actor en concreto:
RESULTADO DE VALOR: Cada ejecución satisfactoria de un caso de uso debe
proporcionar algún valor al actor para alcanzar su objetivo. En algunos casos, el
actor quiere pagar por el valor devuelto. En este caso, el criterio par “un resultado
de valor observable” debe ser aplicado al actor iniciador. Este criterio de
“resultado de valor” nos ayuda a encontrar casos de uso de uso demasiados
pequeños
UN ACTOR EN CONCRETO: Identificando casos de uno que proporcionen valores a
usuarios individuales reales, nos aseguramos que los casos de uso no se harán
demasiados grandes
Estos
ser dosdiferente
muy enfoquesdependiendo
pueden dar valores similares, pero
de la arquitectura el costeAsí
existente. de su implementación puede
puede necesitar
construir que mejor,
un sistema se renegocien
más fácillos
derequisitos
implementar(casos de uso y que
y mantener
el analista
demás)
para los con
de sistemas
el cliente
desarrolladorespara
PASO 3: uso
caso de Describir brevemente cada caso de uso: Consiste en describir aisladamente un
PASO
debe 4: Descripción
incluir del modelo
en eleldiagrama. de casos
Demodelo
hecho, de uso: el
elegimos Noconjunto
hay una de
regla estricta sobre
diagramas lo que se
que plano.
describan
más claramente
También
uso. sistema. El
puede organizarse de
en conjuntos casos de uso
de casos requiere
de uso ser un
llamados modelo
paquetes de casos de
La salida
Esta de este paso
descripción es el
explica también
modelouna
de descripción
casos dese
usogeneral
como undeltodo.
modelo de casos
Describe de uso.
cómo
interactúan los actores y casos de uso y cómo relacionan entre sí los casos de uso.
Página 58
Cuandodel
bueno la descripción
modelo del modelo
de casos de usode casos de
la gente queuso
noesté
formapreparada,
parte dejamos que
deldeterminar
equipo de dé el visto
desarrollo (es
decir, clientes y usuarios), convocando una revisión informal para si:
Se han capturado como casos de uso todos los requisitos funcionales
necesarios
La
usosecuencia de acciones es correcta, completa y comprensible para cada caso de
Se identifica
uso algún caso de uso que no proporcione valor. Si es así, ese caso de
debería reconsiderarse
pueden tener y la posible transición entre estos estados. Cada transición es una secuencia
Página 60
de acciones
efecto de unque se ejecutan
suceso, en unaser
cómo podría instancia del caso de uso cuando ésta se dispara por
un mensaje
Aquí debemos
técnica probadadescribir laun
es elegir posible
caminotransición
básico de estados
completo de manera
desde simple
el estado inicialydescribir
precisa.
hacia Una y
el en
final,
describir
secciones ese camino
separadas
camino básico enresto
el una sección de la descripción.
de los caminos Entonces,
como caminos podemos
alternativos o desviaciones del
Las alternativas,
muchas razones:desviaciones, o excepciones del camino básico pueden ocurrir por
y los usuarios pueden verificar si los casos de uso son los correctos.
intentamos discernir qué se necesita de las interfaces de usuario para habilitar los casos
Página 62
de uso para
creamos cada actor.
el diseño físico Esto
de laes, hacemos
interfaz un diseño
de usuario lógico de la interfaz de usuario. Después,
cómo pueden
especificación utilizar
de qué el
sesistema
necesita los usuarios
antes de parayejecutar
decidir
desarrollamos
cómo realizar la
prototipos
los casos de uso.de
interfaz
que ilustren
Mediante
usuario, la
llegamos aescomprender
actividad las necesidades
esquemasdedeantes de intentar realizarlas. El resultado final de esta
usuario que un conjuntola
especifican deapariencia interfaces
esas de usuario
interfaces de cara ya prototipos
los actoresdemásinterfaces de
importantes.
el código
precisa
La aproximación tradicional a este problema ha sido asignar intermediarios – analistas –
para obtener una lista de requerimientos de cada usuario para poder obtener una visión
de conjunto y de componer una especificación de requisitos completa, correcta y
consistente. Pero es absurdo pensar que la mente humana es capaz de conseguir una lista
consiste y relevante de requisitos del tipo “El sistema debe…”. Es más, estas
especificaciones de requisitos no se transformaban fácilmente en especificaciones de
diseño e implementación
Incluso con la ayuda de los analistas, los usuarios no comprendían del todo lo que el
sistema software debería hacer hasta que el sistema estaba casi terminado. A medida que
el proyecto avanzaba, los usuarios, los intermediarios y los propios desarrolladores
podían ver cómo se parecería el sistema, y por tanto llegaban a comprender mejor las
verdaderas necesidades sugiriéndose gran cantidad de cambios. Muchos de esos cambios
eran deseables pero su implementación tenía con frecuencia un impacto importante en los
El propósito
sistema fundamental
correcto. del flujo de
Estoosecapacidades
consigue trabajouna
mediante de los requisitosde
descripción eslos
guiar el desarrollo
requisitos hacia el
del sistema (es
decir,
como las
paracondiciones
que pueda llegarse a un que el sistema
acuerdo entre debe
el cumplir)
cliente suficientemente
(incluyendo a los buena
usuarios) y los
desarrolladores sobre qué debe y qué no debe hacer el sistema
Un
las reto fundamental
veces seráde para conseguirlo
unrequisitos.
especialista es quedebe
no informático, el cliente, que asumimos
ser capaz de leer que la mayor
y comprender el parte de
resultado
de la
CLIENTEcaptura
para describir Para
estosal alcanzardonde
resultados, este objetivo debemos
losplanificar
resultados del utilizar
flujo deeltrabajo
LENGUAJE
de losDEL
requisitos
cliente también ayudan jefe de proyectos a las iteraciones y las versiones del
Durante la vida del sistema, los clientes, usuarios, analistas y desarrolladores aparecen con
muchas buenas ideas que podrían convertirse en verdaderos requisitos. Esta LISTA DE
algunas
como características
casos de uso. se convierten
La lista detiene en requisitos
características y se SÓLO
se utiliza transforman LAenPLANIFICACIÓN
otros artefactos
PARAexplicación DEL
TRABAJO. Cada
información característica
suficiente para poder un nombre
hablar de ellacorto y unalabreve
durante planificación o definición,
del proyecto
Para capturar los requisitos correctos y para construir el sistema correcto se requiere un
usuario y del
entrevistar cliente.
a los Paradiscutir
usuarios, hacerlopropuestas,
tenemos que comprender el contexto del sistema,
etc.
Página 66
Página 67
entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más.
Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se
guardan en definiciones en un glosario de términos; de otra manera, el modelo de dominio
de haría demasiado grande y requerirían más esfuerzo del necesario para esa parte del
proceso. El glosario y el modelo del dominio ayudan a los usuarios, clientes,
LA COMPRENSIÓN
MODELO DEL CONTEXTO DEL SISTEMA MEDIANTE UN
DEL NEGOCIO
El modelado del
organización. negocio
Pero, ¿qué es una
pasa si técnica
tratamospara
concomprender
un sistema los procesos
que no¿qué de negocio
tienedeberíamos
nada que verdecon
la lo
que la mayoría
desarrollo de undemarcapasos,
nosotros considera
de un un negocio?
sistema de Por anti-bloqueos,
frenos ejemplo, etc.? En hacer
estos en el
casos,
también
Este podemos
sistema (partemodelar
del el sistema
cuerpo humano, que rodea
parte de el
unsistema software
coche, etc.) es elque vamos DE
“SISTEMA a desarrollar.
NEGOCIO”
del sistema software empotrado.
El objetivo esel identificar
comprender contexto. Ellos casos dedeuso
resultado estaque podríamos
actividad modelar
es un que
modelo sólo
de lo necesario
dominio para
derivado de
la comprensión del funcionamiento del “sistema de negocio” lo rodea
En primer lugar, un modelo de casos de uso del negocio describe los procesos de negocio
de una empresa en término de casos de uso del negocio y actores del negocio que se
corresponden con los procesos del negocio y los clientes, respectivamente. Al igual que le
modelo de casos de uso para un sistema software, el modelo de casos de uso del negocio
presenta un sistema (en este caso, el negocio) desde la perspectiva de su uso, y
esquematiza cómo proporciona valor a los usuarios (en este caso, sus clientes y socios)
Un modelo de objetos del negocio es un modelo interno a un negocio. Describe cómo caso
de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan
un conjunto de entidades del negocio y de unidades de trabajo. Cada realización de un caso
de uso del negocio puede mostrarse en diagramas de interacción y de diagramas de
actividad
Una ENTIDAD del negocio representa algo, como una factura, que lo trabajadores toman,
inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio. Una UNIDAD
DE TRABAJO es un conjunto de esas entidades que conforman un todo reconocible para
un usuario final
Página 69
Mediante la utilización de un modelo del negocio como entrada, un analista emplea una
INSTANCIAS O OBJETOS
Una INSTANCIA es una manifestación concreta de una abstracción a la que se puede
aplicar un conjunto de operaciones y que posee un estado que almacena de efecto de las
operaciones
NOTA: Normalmente, la manifestación concreta de una clase se llama objeto. Los objetos
son instancias de clases, por lo que es perfectamente apropiado decir que todos los objetos
son instancias, aunque instancias no son objetos (por ejemplo, una instancia de una
ABSTRACCIONES E INSTANCIAS
Las instancias no aparecen aisladas; casi siempre están ligadas a una abstracción. La
mayoría de las instancias que se modelen en UML serán instancias de clases (y éstas se
llaman objetos), aunque se pueden tener instancias de otros elementos, como
UML también
abstracta, por se utiliza para
definición, no modelar cosas
puede tener que no son
instancias tan concretas.
directas. Sin Por ejemplo,
embargo, unamodelar
seprototípica
pueden clase
instancias
clase directas
abstracta. de clases
Literalmente, abstractas
un objetopara mostrar
así no puedeelexistir.
uso dePero
una instancia
en la práctica, esa de esa
instancia
permite
abstractadar nombre a una de las instancias potenciales de los hijos concretos de esa clase
TIPOS
Una instancia tiene un tipo. El tipo de una instancia real debe ser un clasificador concreto,
pero la especificación de una instancia (que no representa a una instancia en particular)
puede ter un tipo abstracto. En la notación, el nombre de la instancia va seguido de dos
NOMBRES
Cada instancia debe tener un nombre que la distinga de las otras instancias dentro de un
contexto. Normalmente, un objeto existe en el contexto de una operación, un componente
o un nodo. Un NOMBRE es una cadena de texto, como t y miCliente. Ese nombre se le
nombre simple. La abstracción de la instancia puede tener un nombre simple (como
Transacción) o puede tener un NOMBRE CALIFICADO (como Multimedia: :Audio-Stream),
el cual consta de la abstracción precedido por el nombre del paquete en el que ésta se
encuentra
Página 73
El nombre y elPara
Transacción. tipoun
deobjeto
un objeto forman una
(en oposición cadena
a un en la de
rol dentro notación, porestructurada),
una clase ejemplo, t: se
debe subrayar la cadena completa
Página 74
CLASES
Una CLASE es una descripción de un conjunto de objetos que comparten los
NOMBRE
ATRIBUTOS
Un ATRIBUTO es una propiedad de una clase identificada con un nombre, que describe un
rango de valores que pueden tomar las instancias de la propiedad. Una clase puede tener
cualquier número de atributos o no tener ninguno. Un atributo representa alguna
propiedad del elemento que se está modelando que es compartida por todos los objetos de
esa clase. Por ejemplo, toda pared tiene una altura, una anchura y un grosor. Un atributo es
por tanto, una abstracción de un tipo de dato o estado que puede incluir un objeto de la
clase. En un momento dado, un objeto de una clase tendrá calores específicos para cada
OPERACIONES
Una OPERACIÓN es la implementación de un servicio que puede ser requerido a cualquier
objeto de la clase para que muestre un comportamiento. En otras palabras, una operación
es una abstracción de algo que se puede hacer a un objeto y que es compartido por todos
los objetos de la clase. Una clase puede tener cualquier número de operaciones o ninguna.
Página 76
propiedades que los mostrados acabando la lista con puntos suspensivos (”…”)
Para organizar mejor las listas largas de atributos y operaciones, se pueden utilizar
RESPONSABILIDADES
Una RESPONSABILIDAD es un contrato o una obligación de una clase. Al crear una clase, se
está expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el
mismo comportamiento. A un nivel más abstracto, estos atributos y operaciones son
simplemente las características por medio de las cuales se lleva a cabo las
responsabilidades de la clase, una clase SensordeTemperatura es responsable de medir la
MODELOS
Un modelo es una representación, en cierto medio, de algo en el mismo u otro medio. El
modelo capta los aspectos importantes de lo que estamos modelando, desde cierto punto
de vista, y simplifica u omite el resto. Un modelo se expresa en un medio adecuado para el
trabajo que se está realizando. Un modelo de un sistema software está construido en un
lenguaje de modelado, como UML. El modelo tiene semántica y notación y puede adoptar
varios formatos que incluyen texto y gráficos. El modelo pretende ser más fácil de usar
SEMÁNTICA:
de El aspecto
construcciones semántico
lógicas. capta elsemánticos
Los elementos significadodel
de una aplicación como unalared
generación
El aspecto del código,
visual es la comprobación
irrelevante para la de la validez,
mayoría de las las modelo
métricassedeque
herramientas
utilizan para
complejidad,
procesan etc.
modelos. La información semántica a menudo es llamada el modelo
PRESENTACIÓN
considerada, VISUAL:
hojeada Muestra lapor
y corregida información
los seres semánticaNo
humanos. deagrega
modo significado,
que pueda ser
sino
que
útil. organiza la presentación
Por lo tanto, para acentuar
dirigen la comprensión la organización
humana del modelo
del modelo de una manera
CONTEXTO:
de Los más
un contexto modelos
grandesonque
artefactos
les parteen un sistema
dé significado informático
completo. y seque
utilizan
no sedentro
construyen ni de
herramientas utilizan aislados.
modelado, Son
lenguajes de un entorno
y compiladores, más Es decir,
grande
sistemas que incluye
operativos, redes, etc.
nivel. Captura los aspectos esenciales de un sistema y omite algunos de los detalles.
Variaciones en la interpretación
representan
ayudan a los un puntoade
autores partidalashacia
explorar un diseño
opciones del sistema.
posibles Los primeros
antes demodelos
converger modelos
concepto de sistema.
por otros modelos másSegún progresa
exactos. el diseño, los primeros sonen un
sustituidos
descripción completa.
Un modelo
mundo delun
real en dominio
dominio muestra (a los (o
del problema modeladores) clases
de interés). Es conceptuales
el artefacto significativas
más importante quedel
se
crea durante el análisis orientado a objetos.
La
Un identificación
modelo delunde las clases
dominio no de conceptuales
muestra forma parte
componentes del estudiobases
software, del dominio delo problema.
no se trata de
responsabilidades. conjunto diagramas que describen clasescomo
software ude datos
objetos métodos;
software con
Un
del MODELO DELenDOMINIO
mundo real es una
un dominio representación
de interés. visual de las clasesMODELOS
conceptuales u objetos
CONCEPTUALES, MODELO DE OBJETOS EL También
DOMINIOseY los denomina
MODELO DE OBJETOS DE ANÁLISIS.
Este se representa
OPERACIÓN. Puedencon un conjunto de diagramas de clases en los que NO SE DEFINE NINGUNA
mostrar:
ARTEFACTOS SORTWARE
CLASES CONCEPTUALES
El modelo de dominio muestra las clases conceptuales o vocabulario del dominio.
Informalmente, una clase conceptual es una idea, cosa u objeto. Más formalmente, una
dominio con muchas clases conceptuales de grano fino que especificar por defecto
DESCUBRIMIENTO
NOMINALES DE CLASES CONCEPTUALES MEDIANTE LA IDENTIFICACIÓN DE FRASES
Otra técnica útil
descripciones es el análisis
unlingüístico: identificar los como
nombres y frases nominales en las
candidatos. Setextuales
correspondenciadebe de cuidado
tener
mecánica
dominio
con yeste
de nombres
considerarlos
método:
a clases, y las no
clases
es posible
palabras
conceptuales
realizar
en lenguaje una o atributos
natural son
ambiguas.
aEn cualquier
departir de la caso,
uso Procesar
los casos
cal Venta
extraer estede uso enPor
análisis. formato completo
ejemplo, constituyen
se puede utilizar eluna descripción
escenario actualexcelente
del caso
Página 83
mantener en memoria
Quizás el error más típico al crear el modelo del dominio es representar algo como un
atributo cuando debería hacer sido un concepto. Una regla empírica para ayudar a
En el mundo real, una tienda no se considera un número o un texto – el término sugiere una
conceptolegal, una organización, y algo que ocupa espacio –. Por tanto, Tienda debe ser un
entidad
UMLysusvistas
realidad, en todos los sistemas interesantes hay estructuras que trascienden de lo que
Página 85
puede serUML
gráficos, representado
tiene una en un lenguaje
semántica bien de programación.
definida, y se estáUML
bienesdesarrollado,
un de estos lenguajes
se puede
interpretar sin ambigüedad
Versiones
UML cubre la documentación de la arquitectura de un sistema y todos sus detalles. Este
también proporciona un lenguaje para expresar requisitos y pruebas. Por último,
proporciona un lenguaje para modelar las actividades de planificación de proyectos y
gestión de versiones
ELEMENTOS EN UML
más interfaces
INTERFAZ: Es una colección de operaciones que especifican un servicio de una
clase o componente. Por tanto, una interfaz describe el comportamiento visible
externamente de ese elemento. Este puede representar el comportamiento
completo de una clase o componente o sólo una parte de ese comportamiento. La
CASO DE USO
- Clase Activa: Es una clase cuyos objetos tienen uno o más procesos o hilos de
capacidad de procesamiento.
Máquina
por depasa
las que Estados: Es un comportamiento
un objeto durante su vida enque especifica
respuesta las secuencias
a eventos. Puede de estados
incluir
transiciones, eventos, acciones.
Actividad:
proceso. Es un comportamiento que especifica la secuencia de pasos que ejecuta un
Relaciones
Dependencia: Es una relación semántica entre 2 elementos, en la cual un cambio al
Diagramas de…
Clases: Muestra un conjunto de clases, interfaces y colaboraciones, así como sus
diseño de un sistema
Casos de Uso: Muestra un conjunto de CU, sus actores y relaciones. Abarcan la vista
De interacción
dinámica de un(Secuencia y Comunicación/Colaboración):
sistema. Muestran Cubren
el flujo de mensajes entre la vista
objetos.
y sus dependencias
Tiempos: Es un diagrama de interacción que muestra las tiempos reales en el
sistema.
Visión Global de Interacciones: Es un híbrido entre un diagrama de actividades y
uno de secuencia.
Restricciones
ARQUITECTURA
LA VISTA ESTÁTICA
La vista estática es la base de UML. Los elementos de la vista estática de un modelo son
todo tipo de conceptos encontrados en los sistemas. Esta vista captura la estructura del
objeto, e incluye todo lo concerniente a las estructuras de datos tradicionales, así como la
organización de las operaciones sobre los datos. Los datos y las operaciones son
cuantificados en clases.
Página 90
1. Clasificadores
2. Relaciones
Asociación: Lleva la información entre objetos en un sistema. Sin asociaciones,
habrían sólo clases aisladas. Una clase se puede asociar a sí misma, o hacia otra
clase. Los extremos de la asociación pueden tener multiplicidad, es decir, cuántas
instancias de una clase se pueden relacionar con una instancia de otra. Si una
asociación puede tener atributos por sí misma, surge una clase asociativa. Durante
el análisis, las asociaciones representan relaciones lógicas entre objetos. La
Hay 2 subtipos:
o Agregación: Es una asociación que representa una relación todo-parte. Se muestra
adornado
compuesto.
Generalización: Es una relación taxonómica entre una descripción más general
(padre) y una descripción más específica (hijo), que se construye sobre ella y la
extiende. La descripción más específica es completamente consistente con la más
general, y puede contener información adicional. En el caso de clases, se habla de
superclase y subclase. Una generalización se dibuja como una flecha que va desde
o Permitir la herencia
Página 91
Realización: Conecta
comportamiento, unno
pero elemento del modelo
su estructura con otro que especifica
o implementación. su una flecha de
Se indica con
línea discontinua con una punta hueca cerrada
Dependencia:
Indica una Indica una
situación, en larelación
cual semántica
cambio al entre dos oproveedor
más elementos del modelo.
cambio o indicar un cambio en un
el significado elemento
del elemento cliente puede requerir un
en la dependencia.