Ingeniera de software:

Software: programas, archivos de configuracin, manuales de instalacin,

documentacin, etc. Pueden ser productos genricos (de venta en el mercado) o
personalizados (desarrollados especficamente para el cliente). l valor del software es
el valor !ue este le genera al cliente.
"risis del software: son pro#lemas !ue aparecen al desarrollar, mantener $ atender la
demanda. "omprende todos los aspectos de la produccin de software desde las
iniciales al mantenimiento. %a ingeniera de software trata de ser una respuesta a esta
crisis, formulando el pro#lema, analiz&ndolo, #usc&ndole una solucin adecuada $
especifica.
%as actividades de desarrollo implican #'s!ueda de re!uerimientos, an&lisis, dise(o e
implementacin, adem&s de revisiones, prue#as $ la administracin del pro$ecto.
Participan todas las personas involucradas en el pro$ecto: clientes, desarrolladores,
gerentes $ usuarios finales.
"apas del desarrollo de software seg'n Pressman:
)erramientas: a$udan a organizar las tareas de tra#a*o, controlar $ supervisar
los progresos $ administrar la calidad tcnica. Proporcionan un soporte
autom&tico o semiautom&tico.
+todos: indican como realizar los pasos necesarios del ciclo de vida.
Proceso: con*unto de actividades, mtodos, pr&cticas $ tecnologas aplica#les
a todos los procesos del software. ,n proceso #&sico inclu$e an&lisis, dise(o,
codificacin, prue#as $ mantenimiento.
,n enfo!ue de calidad: los cimientos de#en estar enfocados hacia la
calidad.
-ol: papel !ue se le asigna a una persona durante el desarrollo del sistema. ,n
mismo participante puede cumplir varios roles.
Sistema: realidad su#$acente.
+odelo: a#straccin de la realidad.
.ctividad: con*unto de tareas con un propsito especfico.
/area: unidad de tra#a*o elemental capaz de ser administrada. /iene recursos.
-ecursos: #ienes necesarios para realizar el tra#a*o. (*: tiempo).
0#*etivos: Principios de alto nivel para guiar el pro$ecto $ evaluarlos al final.
-e!uerimientos: 1"aractersticas2 del sistema. Pueden ser:
a) 3uncionales: definen el &rea de funcionalidad del sistema.
#) 4o 3uncionales: restriccin al funcionamiento del sistema.
c) 5e 5ominio: normas, decretos, etc.
-estricciones: *: lengua*e de programacin, plataforma, etc.
4otacin: reglas gr&ficas o de te6to para representar un modelo.
+todo: tcnica repeti#le para resolver un pro#lema. (*: algoritmo)
+etodologa: coleccin de mtodos para la resolucin de una clase de pro#lemas.
1.#arca las teoras, mtodos $ herramientas para el desarrollo profesional de software2
7
Ciclos de vida del software
5escri#e las fases del desarrollo de software $ lo !ue se espera e*ecutarse en esas fases.
.$uda a administrar el progreso de desarrollo de software detalladamente.
/ipos:
7) "ascada: desarrollo en fases con metas #ien definidas $ cada una con un
resultado. s difcil de aplicarle cam#ios. Principios:
a. Planear el pro$ecto antes de empezarlo.
#. 5efinir el comportamiento e6terno antes !ue la ar!uitectura interna.
c. 5ocumentar los resultados de cada actividad.
d. 5ise(ar el sistema antes de codificarlo.
e. /estear el sistema antes de construirlo.
8) 9ncremental: -educe riesgos, incrementa su#con*untos de re!uerimientos.
a. "onstru$e un sistema pe!ue(o, lo cual es menos riesgoso.
#. Si aparece un error, solo descarta el avance hecho.
c. vita !ue los re!uerimientos del usuario cam#ien.
:) volutivo: .sume !ue los re!uerimientos no se conocen #ien al principio $
solo toma los seguros, para ir agregando funcionalidad a medida !ue
aparece. "ada paso de#e ser registrado, cada cam#io controlado. s caro.
Produce documentos por iteracin.
;) Prototipado: s una implementacin parcial del sistema !ue es dada a
evaluar a los usuarios para o#tener cierta retroalimentacin. 5e#e ser creado
r&pidamente. Se de#e tener la tecnologa necesaria para llevarlo a ca#o. )a$
falta de visi#ilidad $ #a*o riesgo para nuevas aplicaciones.
<) spiral: 5esarrollo iterativo. "uando uno termina comienza otro
inmediatamente. s fundamental determinar !ue se !uiere hacer antes de
hacerlo, $ los riesgos dispuestos a tolerar. =uena visi#ilidad del sistema, un
documento por iteracin. l e!uipo de#e tener e6periencia. Sigue ; pasos:
7. 5eterminar !ue se !uiere lograr.
8. .rmar rutas para lograrlo con sus pros $ sus contras.
:. Seguir la ruta elegida.
;. sta#lecer !ue es lo !ue ha$ terminado.
Siempre se recomienda usar espiral m&s los necesarios para el sistema a crear.
l prototipado se recomienda para realizar la especificacin de re!uerimientos.
"omo ha$ cam#ios constantes ho$ en da, el enfo!ue es ideal hacerlo evolutivo.
Se de#en com#inar los paradigmas para e6plotar las venta*as particulares de estos.
Modelo IPO
s!uema de funcionamiento del modelo de resolucin de pro#lemas de la inform&tica.
9 > 9nput: datos $ hardware de captura.
P> Proceso: algoritmos, lengua*es de programacin.
0> 0utput: emisin $ generacin de informacin, #ases de datos.
8
Proceso Unificado (UDP)
+etodologa de desarrollo de sistemas orientada a o#*etos. -escata sinta6is $
sem&ntica de ,+%. Posee : conceptos fundamentales:
7) "entrado en los casos de uso: comprendidos por todos los usuarios, intuitivo.
5e#e e6presar todas las funciones $ actores, $ su suma ser el todo.
8) "entrado en la ar!uitectura del sistema a desarrollar: de#en ser incluidos la
plataforma de software $ hardware, los marcos de tra#a*o $ los casos de uso.
:) 5esarrollo iterativo e incremental: se divide el sistema en minipro$ectos $
cada uno es una iteracin en una fase incremental.
a. 3ase 9nicio: descri#e el producto final $ presenta an&lisis de negocio.
5a una visin general de los re!uerimientos del pro$ecto.
#. 3ase ela#oracin: an&lisis del dominio. sta#lece #ase de la
ar!uitectura del sistema. Parte de los casos de uso m&s significativos
para luego completar flu*os. %ista riesgos.
c. 3ase construccin: 5esarrollar incrementalmente el producto. Se
completan casos de uso re!ueridos por el usuario $ luego se hace una
primera entrega a este. Se crea la documentacin de usuario.
d. 3ase transicin: Periodo 1#eta2 del producto. .lgunos usuarios lo
prue#an, se corrigen errores e incorporan me*oras. Se actualiza todo.
"ada fase cuenta con flu*os de:
"aptura de re!uisitos: casos de uso, actores, reglas de negocio. Se
definen estado inicial, orden, estados finales, post condiciones, etc.
.n&lisis: .$uda a especificar me*or los casos de uso, permite razonar
las funciones internas del sistema. 5a camino a los #ocetos de solucin.
5ise(o: 5e#e asegurar solucin a las reglas de negocio, organizadas
en estructura $ comportamiento. 5efinir notacin, software $ relaciones.
9mplementacin: 5escri#e ar!uitectura actual $ plan de integracin
de construcciones.
Prue#as.
:
RUP
5efine cuatro elementos:
%os roles 1?@uinA2. ,n rol define el comportamiento $ responsa#ilidades de un
individuo. 9nclu$e analistas, desarrolladores, etc. ,na misma persona puede tener varios
roles o un rol puede ser realizado por varias personas.
%as actividades 1?"moA2 ,na actividad en concreto es una unidad de tra#a*o !ue una
persona !ue desempe(e un rol puede ser solicitado a !ue realice.
%os productos de tra#a*o 1?@uA2. 5efine un con*unto de artefactos !ue son un trozo de
informacin !ue es producido, modificado o usado durante el desarrollo de software.
%os flu*os de tra#a*o de las disciplinas !ue responde a la pregunta ?"u&ndoA ,n flu*o de
tra#a*o es una relacin de actividades !ue nos producen unos resultados o#serva#les.
B me*ores pr&cticas:
7) 5esarrollo iterativo de software: cada iteracin da un release.
8) .dministracin de re!uerimientos.
:) .r!uitectura #asada con componentes: se #asa en el pronto desarrollo de una
ar!uitectura ro#usta, resistente al cam#io, intuitiva.
;) +odelacin visual de software: captura ar!uitectura $ comportamiento de la
ar!uitectura de componentes.
<) Cerificacin de la calidad de software: crea prue#as para cada escenario.
B) "ontrol de cam#ios del software: controlar, llevar un registro $ monitorear
cam#ios.
structura de -,P: se puede descri#ir en dos dimensiones a lo largo de dos e*es:
7) *e horizontal: /iempo. +uestra el
aspecto din&mico del proceso, e6presado
en ciclos, fases, iteraciones $ metas.
8) *e vertical: representa el aspecto
est&tico del pro$ecto, en trminos de
actividades, artefactos, tra#a*adores $
flu*os de tra#a*o.
9teracin es un ciclo de desarrollo completo. 5a como entrega un producto e*ecuta#le.
;
El modelo de peters:
PetersDtripp: dos autores !ue estudiaron el pro#lema de la ingeniera de software $
sistemas, determinaron un espacio tridimensional formado por tres e*es:
/iempo: ciclo de vida de sistemas
%gica: categoriza actividades realizadas por las personas en cada etapa del
/iempo (distintos roles !ue desarrollan actividades en cada fase !ue se
divide el ciclo de vida de un sistema)
3ormalismo: sucesin $ refinamiento de los distintos modelos !ue van
representando desde el pro#lema hasta la solucin. (es en este e*e donde los
roles de sistemas utilizan distintas tcnicas $ herramientas para modelar,
desde un #os!ue*o mental hasta un sistema totalmente operativo).
ste modelo representa al individuo !ue realiza
actividades de sistemas $ las varia#les !ue de#e
realizar $ !ue afectan su comportamiento
6iste una cuarta varia#le, la e6periencia: varia#le
!ue afecta la lgica $ el formalismo, es decir la
manera de enfocar $ resolver los pro#lemas $ la
utilizacin de los distintos lengua*es de
representacin. 4o puede graficarse.
Correspondencia Peters con RUP
*e /emporal > 3ases -,P (.lgunos dicen -oles),
*e 3ormal > .rtefactos -,P
*e %gico > .ctividades -,P
El Modelo m!iental
l modelo de Peters se complementa con el modelo de am#ientes donde el hom#re de
sistemas desarrolla actividades, tam#in
formado por tres e*es:
0rganizacin !ue plantea
pro#lemas $ reci#e soluciones
de sistemas.
/ecnologa disponi#le para
construir soluciones
/ipo de pro#lema (sistema) a
construir
"ada individuo a travs de su e6periencia
profesional $ pr&ctica ira realizando un
camino !ue lo lleve por un e*e o por mas
de uno, enri!ueciendo su capacidad $
ha#ilidades para resolver $ construir distinto tipos de soluciones de ma$or comple*idad
cada vez.
5ise(o como proceso de resolucin de pro#lemas: se pasa por tres estados:
o 5ivergencia
o /ransformacin
o "onvergencia
l dise(ador imaginar& !ue el sistema fue construido $ es utilizado para decidir detalles.
5ise(o como pro#lema defectuoso: sirve para entender el rol del dise(ador $
cuales son sus desafos
<
l pro#lema no puede ser totalmente planteado, no ha$ regla, no ha$ solucin correcta
l dise(o como respuesta factores crticos.
Ciclo de vida del pro"ecto
Son las fases por las !ue el pro$ecto va pasando desde su inicio hasta su mantenimiento.
5urante este ciclo de vida, ha$ tres varia#les !ue interact'an $ se afectan de manera
recproca: alcance (calidad), tiempo $ costo. %o ideal es e!uili#rarlas.
3ases del ciclo de vida de un pro$ecto:
9niciacin
o .n&lisis de -e!uerimientos: .#arca relevamientos !ue realiza el &rea de
/9 ante re!uerimientos !ue dan origen al pro$ecto.
o studio de 3acti#ilidad: via#ilidad de la solucin planteada para un
re!uerimiento dado. Perspectivas:
/cnica: an&lisis tecnolgico para me*or via#ilidad del pro$ecto.
0perativa: impacto del pro$ecto so#re la organizacin.
conmica: totalidad de gastos para incorporar el sistema,
an&lisis de inversiones, costos $ relacin costoE#eneficio.
o .n&lisis de -iesgos: identificarlos, an&lisis cualitativo $ cuantitativo de
estos. Planificar la respuesta a estos $ su seguimiento $ control.
5ocumento !ue da la fase de inicializacin: 1.nte Pro$ecto2 con datos preliminares.
Planificacin
o 0rganizar el pro$ecto: o#*etivos, alcances, lmites $ restricciones.
o sta#lecer roles en el pro$ecto: roles $ responsa#ilidades en este.
o 5escri#ir interfases e6ternas.
o Planificar tareas $ desglosar su#tareas.
o la#orar el cronograma general: tareas, tiempos, productos e hitos.
o an&lisis de riesgos en la planificacin (Solo en modelo cascada) para
cada iteracin.
5ocumentos de la fase: Plan de pro$ecto $ cronograma general $ de seguimiento.
*ecucin
o *ecutar las tareas planificadas en la fase anterior.
o Proveer los productos entrega#les.
o .*ustar los costos.
o .*ustar los riesgos.
o .*ustar cam#ios en el alcance.
o /ener presente el control de calidad $ Festin de control de los cam#ios.
5ocumentos de la fase: entrega#les, comprometidos, solicitudes de cam#ios, etc.
Seguimiento $ "ontrol:
o fectuar el control $ seguimiento de las actividades planificadas.
o valuar avances planificas contra avance real.
o +onitorear costos $ riesgos del pro$ecto.
o valuar calidad $ oportunidad de productos entrega#les.
5ocumentos de la fase: "ronog de seguimiento actualizado e informes de avance.
3inalizacin: se ela#ora el informe final del pro$ecto contemplando los puntos
m&s importantes $ crticos del pro$ecto finalizado. Servir& para efectuar la
1historia del pro$ecto2, referencia para pro$ectos futuros.
5ocumentos de la fase: informe de cierre de pro$ecto $ plan de pro$ectos updated.
B
#esti$n de re%&erimientos
9ngeniera de re!uerimientos: permite esta#lecer !ue re!uiere un cliente del sistema de
software. Pueden ser funcionales, no funcionales, de dominio, implementacin o datos.
@ue esA: son necesidades de alto nivel de un servicio o de un sistema, destinado a poder
o#tener una especificacin funcional detallada. 5e#en definir todos los inputs u outputs
del sistema. Pueden servir de #ase para contratos.
/areas de los re!uerimientos: e6traccin (para identificarlos), an&lisis $ documentacin.
5efinicin de re!uerimientos: documento con descripcin de los servicios del sistema $
lmites opcionales. s para los clientes.
specificacin de re!uerimientos: documento con descripcin de servicios del sistema.
specificacin de software: descripcin detallada de este. scrito por desarrolladores.
%a o#tencin de los re!uerimientos consiste en identificar el dominio del pro#lema,
definir el software 1contrato2 (especificacin) $ producir el modelo de an&lisis. 0 sea,
especificacin > clientes, mda > desarrolladores. Para o#tenerlos ha$ !ue identificar
actores, escenarios $ casos de uso, $ sus relaciones $ re!uerimientos.
%os pasos para capturar re!uerimientos son:
7) 9dentificar actores: representan entidades e6ternas !ue interact'an con el sistema
(rol). Se les da nom#re a cada uno $ descri#en sus papeles.
8) 9dentificacin de escenarios: descripcin concreta e informal de lo !ue la gente
hace $ e6perimenta al tratar de usar una aplicacin. Ser&n casos de uso.
:) 9dentificacin de casos de uso: especifica todos los escenarios para una
funcionalidad. %o inicia un actor. s un flu*o completo del sistema.
;) 5escripcin de casos de uso: caminos #&sicos, caminos alternativos,
precondiciones (estado inicial), descripciones, etc.
<) 5iagramas de estado: descri#en estados $ transiciones entre ellos. 5e actividad:
descri#en transicin en detalle. 5e interaccin: descri#en interaccin cduDactor.
B) Prototipado de la interfaz:
a. 5ise(o lgico: se plantean los elementos de interfaz necesarios para el
caso de uso, la relacin entre estos, como se aplican a los casos de uso,
su apariencia $ modo de manipulacin. %uego, cual usa cada actor.
#. 5ise(o fsico: se preparan es!uemas de la configuracin de elementos de
las interfaces, $ #ocetos adicionales para com#inar varios elementos de
interfaz $ se constru$en prototipos e*ecuta#les de lo m&s importante.
G) structurar el modelo de caso de uso: 6traer descripciones de funcionalidad de
casos de uso generales $ compartidas !ue pueden ser creadas por casos de uso
especficos, e6tenderlas o incluirlas.
a. -elaciones de generalizacin: simplifican forma de tra#a*o $
comprensin. Permiten reutilizar casos de uso.
#. -elaciones de e6tensin: se puede incluir el comportamiento
caso en otro #a*o ciertas circunstancias. Solo para casos
e6cepcionales.
c. -elaciones de inclusin: permiten evitar redundancias $
reutilizar casos de uso. Solo para comportamientos
compartidos entre casos de uso.
l diagrama de casos de uso de#e ser intuitivo, comprensi#le $
mostrar todos los casos de uso del sistema..
G
UM'
%engua*e unificado de modelado. st&ndar para construir planos de software.
Se de#era usar en un proceso dirigido por casos de uso, centrado en la ar!uitectura,
iterativo e incremental.
s una notacin, no una metodologa.
Su sinta6is son sus diagramas, su sem&ntica el paradigma orientado a o#*etos.
Se compone de tres elementos #&sicos:
7) =lo!ues de construccin: ha$ de tres clases:
a. lementos: estructurales, de comportamiento, de agrupacin $ de
anotacin.
#. -elaciones: dependencia, asociacin, generalizacin $ realizacin.
c. 5iagramas: varios, seg'n lo !ue se desee representar (clases, o#*etos,
casos de uso, etc.)
8) -eglas: pautas para realizar asociaciones entre o#*etos.
:) +ecanismos comunes: par !ue cada persona o entidad adopte ,+% a sus
necesidades.
%as < vistas de una ar!uitectura de software: varan seg'n perspectiva $ momento:
7) Cista de casos de uso: descripcin del comportamiento tal como es visto por
el usuario final.
8) Cista de dise(o: clases, interfases $ cola#oraciones !ue forman el
voca#ulario dl pro#lema $ la solucin.
:) Cista de procesos: funcionamiento, capacidad de almacenamiento $
rendimiento del sistema.
;) Cista de implementacin: "omponentes $ archivos para hacer disponi#le el
sistema fsico.
<) Cista de despliegue: distri#ucin, entrega e instalacin.
5iagramas para partes est&ticas de un sistema:
7) "lases: muestran clases $ o#*etos, *unto con sus
contenidos $ relaciones, es decir el nom#re de la
clase, los atri#utos $ las operaciones.
8) 0#*etos: Se muestran igual !ue como en una clase.
+uestran un 1snapshot2 del sistema en un momento
determinado.
:) "omponentes: descri#e elementos fsicos de un sistema $ sus relaciones.
;) 5espliegue: configuracin de componentes hardware $ distri#ucin de
procesos en los mismos.
5iagramas de comportamiento de ,+%:
<) "asos de uso: ilustra los re!uerimientos funcionales e un sistema $ como se
comporta este ante eventos.
B) Secuencia: muestra interaccin entre o#*etos de una
aplicacin en el tiempo. s como una pelcula de
nuestro sistema planteado en un escenario.
G) "ola#oracin: +uestra como interact'an los o#*etos en el
tiempo, teniendo en cuenta tam#ien las relaciones entre
ellos. o#*etos en formato 1red2 $ sus relaciones.
H
H) stados: descri#e todos los estados posi#les de un o#*eto $ como cam#ia
seg'n eventos.
I) .ctividades: 6pansin del diagrama de estados, muestra un mtodo, un
caso de uso, un worJflow, etc.
Modelado de datos:
+odelo conceptual: define caractersticas del negocio fuera de la implementacin.
5ise(o lgico de la #ase de datos: solucin tecnolgica #asada en el modelo conceptual.
structuras de datos: atri#utos !ue descri#en a una entidad.
ntidades: ideas de las !ue tengo !ue guardar informacin para comprender el negocio.
.tri#utos: caractersticas !ue permiten descri#ir cada e*emplar de una entidad.
-elaciones: vinculaciones entre entidades (ideas).
"ardinalidad: numero de instancias de una entidad !ue pueden relacionarse
con un n'mero de instancias de otra.
+odalidad: indica si la relacin entre entidades es o#ligatoria o no.
Frado: numero de entidades !ue participan de una relacin.
specializacinEFeneralizacin: vnculos *er&r!uicos.
(ormali)aci$n:
"lave candidata: 7 a n atri#utos, siempre ha$ al menos una, pero pueden ser varias.
"lave primaria o principal (PK): clave candidata elegida. "umple unicidad.
"lave alternativa: no fueron elegidas como PK.
"lave for&nea (3K): con*unto de atri#utos !ue es clave de otra 5. Pueden no formar
parte de la PK de la estructura en la !ue est&n.
/cnica de normalizacin: se parte de un 'nico con*unto de atri#utos o es!uema
relacional. Se tienen las PK. %a idea es me*orar el es!uema sin perder informacin ni
dependencias funcionales. /odo atri#uto de cada nueva 5 de#e estar determinado por
atri#utos de la misma 5, con su propia PK. . la 5 original no se le !uitan ni suman
atri#utos. ntre la estructura nueva $ la original de#en tener alg'n atri#uto en com'n $
estos ser&n parte de la clave en alguno de los dos. Pasos:
7) 3orma "annica: Se eliminan de la 5 los atri#utos calcula#les.
8) Primera 3orma 4ormal: "umple si no tiene atri#utos repetitivos (toman
distintos valores). *: tracJL7,7MN. %a 5 original conserva su clave $ la
nueva tiene la clave original m&s atri#utos propios. %a relacin es 7 a
muchos hacia nueva 5.
:) Segunda 3orma 4ormal: cumple si $ solo si los atri#utos !ue no son clave
dependen de ella en su totalidad. %a 5 original conserva su clave $ la nueva
solo una parte de la 5 $ sin atri#utos propios. %a relacin es de 7 a muchos
hacia la estructura original.
;) /ercera 3orma 4ormal: "umple si no ha$ dependencias funcionales entre
atri#utos no claves. %a 5 original conserva su clave $ la nueva usa atri#utos
no primos de la 5 original. %a relacin es de uno a muchos hacia la 5
original.
<) ="43: /odo determinante es clave candidata. Suelen ser reglas de negocio.
Si todos son PK est& en ="43.
/ips: %as 5 nunca se agrandan, las claves nunca se achican, dos 5 relacionadas
tienen por lo menos un atri#uto en com'n.
5ependencia funcional: si conozco el atri#uto a puedo conocer a =.
%a normalizacin asegura !ue el modelo conceptual tra#a*a #ien, si no normalizo puedo
tener caos de datos, llamados 1anomalas2.
I
%a normalizacin se lleva a ca#o en funcin de las relaciones $ no en funcin de los
datos.
#esti$n De Pro"ectos:
Pro$ecto: con*unto de actividades planificadas, coordinadas, e*ecutadas $ controladas
para alcanzar o#*etivos conforme a re!uerimientos $ restricciones, a realizarse de forma
ordenada, en tiempo $ forma.
"aractersticas: temporal, resultado 'nico, o#*etos claros, no es un servicio a #rindar.
5imensiones de un pro$ecto:
7) /cnica: #usca !ue el resultado sea acorde a lo pedido.
8) conmica: el resultado de#e ser via#le.
:) "omercial: imagen !ue se generar& $ afectar& a los clientes.
;) stratgica: permite ad!uirir e6periencia $ tecnologas para competir.
3ases:
7) "oncepcin del pro$ecto: cuando surge una idea via#le.
8) 5esarrollo: planificarlo. sta#lecer fechas.
:) -ealizacin: administracin $ control del pro$ecto.
;) Puesta en marcha: se hacen las prue#as finales $ pone en marcha como tal.
-esolver un pro#lema implica realizar procesos de razonamiento comple*os $ no
simplemente una actividad asociativa $ rutinaria.
n todo proceso de decisiones ha$ !ue definir mu$ #ien el pro#lema, $a !ue cliente no
sa#e #ien !ue es lo !ue !uiere. ,na vez definido el pro#lema ha$ !ue definir o#*etivos,
para luego definir metas $ los pasos para alcanzarlos.
7M
Ingeniera *e!
)a$ !ue desarrollar soluciones #uenas, implementa#les, pro#adas $ de calidad.
%os sistemas Oe# mezclan pu#licacin impresa $ desarrollo de software, marJeting,
inform&tica $ relaciones e6ternas.
.tri#utos de una we#app:
7) 9ntensidad de red: satisfacer a una variada cantidad de clientes.
8) "oncurrencia: pueden usarla varios usuarios a la vez en cual!uier momento.
:) 5esempe(o $ disponi#ilidad: estar siempre en lnea $ utiliza#le.
;) s go#ernada por los datos, evoluciona constantemente, segura $ esttica.
"ategoras: informativa, descarga, personaliza#le, transaccin, servicio, etc.
-e!uisitos: identificar re!uisitos de contenido funcionales $ definir escenarios de
interaccin. 5efinir casos de uso.
!uipo: desarrolladores, editores, ingenieros, soporte, we#master, etc.
rrores: pensar en tener todo 1ahora mismo2, su#estimar los cam#ios, #urocratizarse, no
hacer las prue#as suficientes.
.n&lisis de una we#app:
7) "ontenido: se identifica el espectro completo de contenidos.
8) 9nteraccin: como interact'a el usuario con la we#app (cdu, estado, etc).
:) 3uncional: escenarios (casos de uso) definen como operar& internamente.
;) "onfiguracin: am#iente e infraestructura del we#app.
+odelo de dise(o para we#app: de#e ser seguro, estar disponi#le, escala#le.
a) +etas: consistente interna $ estticamente en todo el we#app.
#) 0#*etivos: identidad para el propsito del negocio, ro#usta $ relevante,
navegacin intuitiva, visual appeal (sensacin de contenido), compati#ilidad
con am#ientes $ facilidad de configuracin.
Principios: anticiparse al usuario, comunicar el estado actual, consistencia, centrado en
la tarea actual, minimizar el tiempo de aprendiza*e, integridad del producto, legi#ilidad.
5ise(o de interfase: visualmente evidente. 5e#e perdonar errores $ permitir deshacer.
5ise(o esttico: acentuar el contenido, organizar arri#aDiz!uierda a#a*oDderecha.
.grupar en la p&gina, considerar la resolucin de pantalla.
5ise(o de contenidos: representa el mecanismo para instanciar relaciones de uno a otro.
5ise(o de navegacin: cada actor lo usar& con distintos re!uisitos seg'n su *erar!ua $
los casos de uso asociados.
5ise(o de ar!uitectura: como los o#*etos son estructurados para presentacin $
navegacin por parte del usuario. Se realiza paralelo a otros dise(os.
5ise(o a nivel componente: navegacin din&mica, computacin, consultas a #ases de
datos sofisticadas, interfase, etc.
1%a 9ngeniera Oe# trata con enfo!ues disciplinados $ sistem&ticos para el desarrollo,
despliegue $ mantenimiento de los sistemas $ aplicaciones #asados en Oe#2
Pir&mide de dise(o para we#apps: Son los B casos de
dise(o comenzando desde la importancia del usuario
hasta tecnologa en el siguiente orden:
Pcima: usuarioQ
PinterfazEestticoEcontenidoEnavegEar!uiEcomponenteR
P#ase: tecnologaQ
77
Reingeniera
1+odificacin de un producto software, o de ciertos componentes, usando para el
an&lisis del sistema e6istente tcnicas de 9ngeniera 9nversa $, para la etapa de
reconstruccin, herramientas de 9ngeniera 5irecta, de tal manera !ue se oriente este
cam#io hacia ma$ores niveles de facilidad en cuanto a mantenimiento, reutilizacin,
comprensin o evaluacin.2
Centa*as:
Pueden reducir los riegos evolutivos de una organizacin.
.$uda a las organizaciones a recuperar sus inversiones en software.
Puede hacer el software m&s f&cilmente modifica#le
.mpla las capacidades de las herramientas ".S
s un catalizador para la automatizacin del mantenimiento del
software.
.ctividades involucradas para lograr me*ores versiones de programas e6istentes:
.n&lisis de 9nventarios: modelo !ue inclu$e informacin detallada de las
aplicaciones activas. %os candidatos a la reingeniera aparecen cuando se
ordena esta informacin en funcin de su importancia para el negocio,
longevidad, manteni#ilidad actual, etc. s entonces cuando es posi#le
asignar recursos a las aplicaciones candidatas para el tra#a*o de reingeniera.
-eestructuracin de documentos: %a documentacin de#e actualizarse pero
se tiene recursos limitados. Se utiliza un enfo!ue de 1documentar cuando se
to!ue2. l sistema de#e volver a documentarse por completo.
9ngeniera 9nversa: *: una compa(a tiene un mu$ #uen producto, pero sus
documentos son privados. Se trata de partir desde este producto con
e*emplos reales para llegar a la 1frmula2. %a ingeniera inversa del software
es el proceso de an&lisis de un programa con el fin de crear una
representacin de programa con un nivel de a#straccin m&s elevado !ue el
cdigo fuente. %a 9ngeniera inversa es un proceso de recuperacin de
dise(o.
-eestructuracin de cdigo: es el tipo m&s com'n. Se puede hacer con
mdulos individuales !ue se codifican de una manera !ue dificultan
comprenderlos, pro#arlos $ mantenerlos. %levar a ca#o esta actividad
re!uiere analizar el cdigo fuente empleando una herramienta de
reestructuracin, se indican las violaciones de las estructuras de
programacin estructurada, $ entonces se reestructura el cdigo. l cdigo
reestructurado resultante se revisa $ se comprue#a para asegurar !ue no se
ha$an introducido anomalas. Se actualiza la documentacin interna del
cdigo.
-eestructuracin de datos: %a ar!uitectura de datos actual se analiza con
minuciosidad $ se define los modelos de datos necesarios, se identifican los
o#*etivos de datos $ los atri#utos, $ despus se revisa la calidad de las
estructuras de datos e6istentes. "uando la estructura de datos es d#il se
aplica una reingeniera a los datos. %os cam#ios en datos dar&n lugar
invaria#lemente a cam#ios o #ien de ar!uitectura o #ien de cdigo.
78
9ngeniera directa: %a ingeniera directa no solo recupera la informacin de
dise(o a partir del software e6istente, tam#in utiliza esta informacin para
alterar o reconstruir el sistema e6istente con la finalidad de me*orar su
calidad glo#al. n la ma$ora de los casos el software sometido a
reingeniera vuelve a implementar la funcin del sistema e6istente $ tam#in
a(ade nuevas funciones o me*oras.
+istemas de ,iempo Real
s un sistema su*eto a restricciones de tiempo. Puede ser uno de estos tres:
7) )ard (stricto): opera mal si los resultados no son a tiempo (*: marcapasos)
8) Soft (3le6i#le): la operacin se degrada si no es en tiempo (*: telefona)
:) 3irm (3irme): se admite un grado de falla si no es a tiempo (*: monitoreo)
. su vez, se pueden clasificar en:
a) 5e +onitoreo: recolecta datos de sensores, pero no activadores en tr.
#) 5e "ontrol: toman datos de sensores $ los envan a activadores.
c) 5e captura de datos: capturan datos de sensores para futuros an&lisis.
Sistemas de estmulosDrespuestas: dado un estmulo de#en responder en un tiempo
especificado !ue puede ser peridico (predeci#le) o aperiodico (impredeci#le).
lementos del sistema:
7) Procesador de control de sensores: recolectan datos de sensores (entorno).
8) Procesador de datos: procesa la informacin calculada $ calcula la respuesta
del sistema.
:) Procesador de control de actuadores: genera se(ales de control (signals) para
actuadotes (cam#ian con el entorno)
Proceso de dise(o de un sistema en tiempo real:
9dentificar estmulos $ respuestas esperadas.
5efinir las restricciones de tiempo.
.gregar funciones del sistema en procesos concurrentes.
5ise(ar algoritmos para estmulos $ generacin de respuestas.
5ise(ar planificacin !ue asegure !ue los comienzos ser&n en tiempo para
cu#rir descone6iones.
9ntegrarlo con un e*ecutivo tiempo real o con el sistema operativo.
"omponentes del e*ecutivo en tiempo real:
-elo* de tiempo real: provee informacin para scheduling de procesos.
+anipulador de interrupciones: mane*a solicitudes aperidicas de servicios.
Planificador (scheduler): define el pr6imo proceso a e*ecutar.
.dministrador de recursos: aloca recursos de memoria $ procesador.
5espachador de procesos: lanza la e*ecucin de procesos.
"omponentes de un sistema nonDstop:
.dministracin de configuracin: reconfigura din&micamente sof& $ hard.
.dministrador de fallas: detecta las fallas $ las tra#a*a.
strategia de planificacin: completa, con interrupcin, scheduling (--), m&s corto, etc.
stados posi#les de un sistema tiempo real: e*ecutando (mediante
se(al de #lo!ueo pasa a:), #lo!ueado (mediante se(al de planear pasa
a:), listo (mediante se(al de escalonamiento pasa a:), planificado.
Puntos clave:
D 4o depende de !ue ni como, solo lo r&pido !ue reaccione.
D ,n modelo general inclu$e la asociacin de procesos con actores $ sensores.
7:
D l e*ecutivo de tiempo real es responsa#le del proceso de administracin de
recursos.
D %a captura de datos generalmente sigue el modelo productorEconsumidor
D tc :P
Redes de Petri
specifica el comportamiento de sistemas asincrnicos. 3ormalismo gr&fico. Se pueden
interpretar como un modelo de descripcin de sistemas concurrentes.
4o propone ninguna pr&ctica para resolver situaciones de conflicto.
sta formado por tres tipos de componentes:
7) Plazas o lugares (crculos): posi#les estados del sistema.
8) /ransacciones (rect&ngulos): acciones !ue cam#ian estados.
:) .rcos (flechas): conecta plaza con transaccin o viceversa.
S estos arman un grafo donde con cospeles muestra el comportamiento del
sistema en un momento. %as reglas son:
7) ,na transaccin puede tener uno o m&s entradas de lugares.
8) ,na transaccin puede tener una o mas salidas de lugares.
:) 3lecha lugar DQ transicin > entrada (viceversa > salida).
;) ,na transicin es permitida si e6iste al menos un cospel en todas sus
entradas. S esto lo ha#ilita tam#ien a disparar los cospeles.
"aso Starvation: l sistema se !ueda a la espera de algo !ue no sucede. Se forma
un 1ciclo infinito2
"aso 5eadlocJ: s un con*unto de procesos en un estado de espera tal !ue
ninguno de ellos tiene suficientes criterios para continuar su e*ecucin.
"aso "oncurrencia: Se puede elegir entre dos opciones indistintamente.
D-D,R
-ecuperacin ante fallas
Celocidad de respuesta
.lta criticidad
+inimizar el error
)ardware $ software especficos
Scheduler
4o ha$ restauracin de actividades
Sensor E actuador
"omponentes: ("rculo) > datos R ("rculo punteado) > "ontrol R flechas > control.
Pasos:
7) realizar el diagrama de proceso de datos 'nicamente
8) 5eterminar cuales son los o#*etos !ue cam#ian de estado
:) -ealizo el 5/ de cada uno de esos o#*etos
;) 9ncorporo el diagrama del punto 7 los proceso de control de cada uno de los
o#*etos !ue encontr en el paso 8.
<) -efino el 535 si es necesario.
7;
r%&itect&ra de sistemas:
/raduce el dise(o lgico de un sistema de informacin en una estructura fsica.
Se de#en considerar lineamientos de dise(o como planeamiento, costos, escala#ilidad,
integracin Oe#, seguridad, procesamiento e integracin con otros sistemas.
"ada sistema de informacin involucra tres funciones:
7) .lmacenamiento $ acceso a datos.
8) %a lgica de procesamiento de la aplicacin.
:) %a interfaz para interactuar con el sistema (servidor T cliente T am#os)
.r!uitectura clienteEservidor: es un modelo de sistemas distri#uido. "on*unto de
servidores !ue proporcionan servicio cuando el cliente lo re!uiere. 5istri#u$e datos $
favorece red. 5esventa*as: administracin redundante, no comparte con otros sistemas.
Puede tomar muchas formas seg'n el servidor. )a$ dos tipos de clientes: gordo (denso)
$ flaco.
"apas clienteEservidor: dise(o en 8 capas E dise(o en : capas E middleware.
.r!uitectura en : capas:
5ividida fsicamente (servidor de #ase de datos E aplicaciones E Oe# E
cliente)
5ividida lgicamente (presentacin E reglas de negocio E acceso a datos )
=asada en componentes
%a capa lgica contiene componentes de interfaz usuarios, proceso de usuario de
negocio, interfaz de servicios, agentes de servicios, componentes de acceso a
datos, servicios comunes, etc.
+todos de procesamiento:
n lnea: procesa cuando ocurren las transacciones. ,suarios interact'an en
el momento, siempre disponi#le.
n lotes: se almacenan en loteas $ procesan en grupos.
"om#inado: mezcla en lnea $ en lotes.
0rganizar el dise(o ar!uitectnico favorece la comunicacin con los staJeholders,
analizar el sistema, etc.
0tras ar!uitecturas:
+odelo repositorio: distintos sistemas comparten datos en un repo com'n.
+&!uina a#stracta: el sistema se organiza en capas, cada una proporciona un
con*unto de servicios. Puede ser incremental.
.dministrador de versiones:
o (.dm. Cer. (.dm. 0#*. (Sist. =ase de 5atos (Sisop))))
+odelos de control: relaciona partes del sistema.
"entralizado: es responsa#le del mane*o de otros su#sistemas.
=asado en eventos: cada sistema responde a determinados eventos, el tiempo
del evento esta fuera del control de los su#sistemas !ue lo procesan.
7<
,esting:
valuar un sistema manual o autom&ticamente para verificar !ue satisface los re!uisitos
esperados o identificar la diferencia entre los esperados $ los reales.
0#*etivos: me*orar la calidad del software, reducir errores, reducir costos.
%o realizan los desarrolladores, los analistas @. (tester) $ los analistas funcionales.
+etodologa: an&lisis (revisin de los casos de uso), especificacin de los casos de test,
e*ecucin de estos, generacin de resultados, depuracin (desarrolladores).
strategias:
a) 9ntegracin: pro#ar todo luego de cada mdulo o funcionalidad.
#) -egresin: encontrar causas de nuevos errores $ pro#lemas luego de
una nueva funcionalidad.
c) ,nitarias: para pro#ar un mdulo de cdigo.
/ipos de test:
a) "a*a #lanca: se prue#a el 7MMU del cdigo contemplando todas las
com#inaciones $ rutas lgicas.
#) "a*a negra: solo desde el punto de vista de las entradas $ salidas, sin
importar el adentro.
c) Stress test: se trata de hacer andar mal para encontrar cuellos de #otella,
concurrencia $ performance.
d) ,sa#ilidad: caractersticas de ergonoma $ usa#ilidad.
e) Calidacin $ aceptacin: las realiza el usuario para apro#ar.
/est 5riven 5evelopment (/55): 5esarrollo guiado por prue#as. 4o es un tipo de
testing sino una practica de programacin !ue involucra otras dos pr&cticas: scri#ir las
prue#as primero $ refactorizacin. Principios: no se puede escri#ir cdigo productivo si
no es para arreglar un test fallido, $ asiV.
ntornos:
ntorno de test: es propio, administrado por la
empresa. %o hacen los @., .nalistas funcionales
$ desarrolladores.
ntorno de preDproduccin: administrado por
el cliente. Se hace para !ue este de el 0K antes de
iniciar el deplo$. Participan @., .3 $ el cliente.
ntorno de produccin: una vez !ue se tiene el
0K se coordina el deplo$ general. Feneralmente son prue#as funcionales.
Participan clientes $ .3.
"onfeccin del caso de test: este contiene:
+odulo: con nom#re del mdulo a pro#ar.
"digo de test: identificador del test particular.
5escripcin: lo necesario para e6plicar el test.
7B
Pre T condiciones: las especificadas en el caso de uso correspondiente.
Paso a paso: claramente los pasos para desarrollar la prue#a.
-esultado esperado: como de#era responder el sistema.
-esultado o#tenido: como respondi el sistema. -esultado del test.
stado: grado de satisfaccin de la respuesta o#tenida.
*ecutado por: persona !ue hizo el test, fecha $ versin del documento test.
Puntos mnimos a testear: pantalla, datos guardados, campos re!ueridos, flu*os del caso
de uso, un caso por regla de negocio $ por cada flu*o alternativo.
.utomatizacin del test: usando software. nfo!ues: guiado o con interfaz gr&fica.
=eneficios: productividad, velocidad de e*ecucin, dinamismo, 1no se cansa2.
Proceso de dise.o:
l proceso de dise(o es el proceso de aplicar distintas tcnicas $ principios con el
propsito de definir un dispositivo, un proceso o un sistema con el suficiente detalle
como para permitir su realizacin fsica. s un proceso iterativo !ue puede traducir
re!uisitos en representacin software.
5ise(o de datos: transforma el modelo del dominio en estructuras de datos.
5ise(o ar!uitectnico: estructura modular del programa o aplicacin.
5ise(o de interfaz: interfaces del software con otros sistemas o usuarios.
5ise(o procedimental: descripciones de los componentes del software.
Se dispone de entradas, salidas, funciones, es!uemas lgicos de datos.
Principios: a#straccin, modularidad, encapsulamiento.
Dise.o estr&ct&rado:
+todo de configuracin de la estructura modular del software !ue se desarrolla a partir
de flu*os de datos !ue contiene la especificacin de re!uerimientos !ue da la fase de
an&lisis. Se #asa en funciones 'nicas (programas) de relativa independencia.
+dulo: unidad claramente definida $ mane*a#le !ue forma parte del software.
+odularidad: particionar software en elementos con nom#res $ direcciones separadas
(mdulos) simples con menos error, f&cil evaluacin $ altera#les.
3an 0ut: medida de mdulos directamente controlados por otro mdulo.
3an 9n: cuantos mdulos controlan otro mdulo.
.#straccin: un nivel superior de a#straccin supone solucin en trminos amplios,
niveles m&s #a*os, son m&s procedimentales.
.coplamiento: grado de independencia entre dos mdulos. )a$
!ue lograr independencia entre estos eliminando relaciones
innecesarias. /ipos:
4ormal: . llama a =, = retorna el control a .. 4o ha$ paso de par&metros.
Por datos: se comunican por par&metros (dato elemental).
Por estampadoEimagen: refieren a la misma estructura de datos local.
"ontrol: pasa al otro mdulo elementos de control (flags, switchs).
"om'n: se refieren a la misma estructura glo#al.
"ontenido: es inacepta#le. una referencia al interior del otro.
5os mdulos pueden presentar m&s de un tipo de acoplamiento, !uedando el
peor como caracterstico.
"ohesin: relacin funcional de los elementos de un mdulo, me*or si es grande. /ipos:
3uncional: contri#u$e a hacer una $ solo una tarea.
(*: coseno 6)
Secuencial: salida de una, entrada de otra.
7G
"omunicacional: contri#u$e a actividades !ue usan misma entrada o salida.
Procedimental: elementos en actividades diferentes $ posi#lemente no
relacionados pero el control flu$e de una a otra.
/emporal: por tiempo para e*ecutarse.
%gica: la actividad a e*ecutarse se selecciona desde afuera del mdulo
"oincidencial: por casualidad.
5ise(o centrado en transformaciones: los datos entran al sistema con flu*os de entradas
$ se transforman en el n'cleo. Salen por flu*os de salida.
5ise(o centrado en transacciones: se presenta un centro de transaccin como un centro
de flu*o de informacin, de ah surgen n'cleos $ caminos alternativos (e6clu$entes)
Dise.o de interfases:
F,9: es una interfaz para reci#ir, comunicar, visualizar $ documentar datos de un
sistema orientado a la comunicacin con el usuario. 5e#e ser amiga#le con este,
mostrarle todo el sistema.
"aractersticas: ventanas, iconos, men's, punteros, gr&ficos, sonidos, colores.
Centa*as: f&ciles de entender $ usar, r&pida capacitacin, tareas simult&neas, usan la
visin del usuario final.
5esventa*as: utilizan muchos recursos, comple*as de programar, lentas.
%as F,9s muestran al usuario las #ondades del sistema, facilitan el ingreso de datos,
permite visualizar como desea el usuario $ reducen la comple*idad del sisop.
.tri#utos de una #uena F,9:
.prendi#ilidad: tiempo promedio de aprendiza*e del usuario.
Celocidad de operacin: tiempo de respuesta para el usuario e6perto.
-o#ustez: tolerancia a errores.
-ecupera#ilidad: porcenta*e de recuperacin de errores.
.dapta#ilidad:
Principios de dise(o de una F,9:
3amiliaridad con el usuario: !ue lo entienda, no usar lengua*e tcnico.
"onsistencia: lo similar, tratarlo igual.
Sorpresa mnima: resultados predeci#les.
-ecupera#ilidad ante fallas: autorecuperacin de errores.
Fuas de usuario: manuales accesi#les, guas de uso claras.
5iversidad de usuarios: complacer a todos (*: tama(os de letra).
9nteraccin usuario con sistema:
+anipulacin directa: es r&pido $ f&cil de aprender, el usuario toma el
control. s difcil de implantar. (*: Cideogames).
Sistemas de men': se presentan opciones a elegir. 4o ha$
!ue memorizar comandos, tipeo mnimo, se evitan errores.
Pero son fi*os $ se pueden tornar comple*os si ha$ muchas
opciones. %entos. (*: Sistemas de propsito general).
3ormularios de ingreso: 9ngresa al sistema datos de usuario
(*: altasE#a*as). s guiado $ de r&pida capacitacin. =a*o
mane*o de e6cepciones. (*: stocJ).
%engua*e de comandos: tcnico, preciso, poderoso, directo,
sem&ntica rgida. -&pida interaccin con el sistema. -e!uiere
conocimiento e6perto. s inusa#le para ciertos usuarios. (*:
Sistema 0perativo).
7H
%engua*e de programacin: simple, restringido, poderoso. -&pida interaccin
con el sistema. -&pido.
Presentacin de informacin de F,9s: directa (n'meros), transformada (alg'n estilo
gr&fico), esttica, din&mica.
4o ha$ !ue usar mucho color *unto, el usuario de#e poder cam#iarlos.
,sar a$udas para el usuario.
5ise(o crtico del error, mensa*es po#res pueden producir rechazo. )a$ !ue considerar
el conte6to, e6periencia del usuario, de#e ser optimista.
/e&rsticas
-eglas de #ase emprica, avaladas por la e6periencia $ compro#adas. Permiten asegurar
la calidad del dise(o.
/e&rsticas De Dise.o
%as heursticas de dise(o son un con*unto de datos !ue a$udan a me*orar la estructura
del sistema, optimizando la secuencia.
/ama(o de +dulo: l tama(o del mdulo est& relacionado con la modularidad, m&s no
solo de manera simple de 1cortar en programa en m&s piezas2. sto es, la modularidad
tcnica no se incrementa simplemente cuando el tama(o de mdulo decrece, mientras
otros aspectos permanecen igual. 4o siempre mdulos mu$ grandes o mu$ pe!ue(os
son necesariamente malos. %a cuestin importante es !ue los mdulos refle*en la
estructura del pro#lema lo m&s fielmente posi#le.
.mplitud del "ontrol (3anDout): %a amplitud del control o ancho de salida (fanDout), es
el n'mero de su#ordinados inmediatos de un mdulo. .l igual !ue en con el tama(o de
mdulo, amplitudes de control mu$ altas o mu$ #a*as, son indicadores de un posi#le
dise(o po#re.
.ncho de ntrada (3anD9n): Siempre !ue sea posi#le, desearemos ma6imizar el ancho
de entrada de un mdulo (fanDin) durante el proceso de dise(o. "ada instancia de
m'ltiples entradas de un mdulo, representa !ue ha podido evitarse duplicidad de
cdigo.
.lcance de fecto E .lcance de "ontrol: l alcance de efecto de una decisin es la
coleccin de todos los mdulos !ue contienen alg'n procesamiento !ue est&
condicionado por dicha decisin. l alcance de control de un mdulo es el mdulo
mismo $ todos sus su#ordinados. Para una decisin dada, el alcance de efecto de#e ser
un su#con*unto del alcance de control del mdulo en el cual se encuentra la decisin.
+ez!uita: Feneralmente, si el fanDout es demasiado alto, entonces el mdulo e*ecutivo
tiende a ser demasiado comple*o, $ la modularidad efectiva de todo el sistema se
decrementa. n los sistemas #ien dise(ados encontramos un fanDout promedio de tres o
cuatro. %a forma de mez!uita es una caracterstica de los sistemas #ien dise(adosW pero
es potencialmente peligrosa si se usa como herramienta de dise(o. /iene un fanDout alto
en los mdulos de ma$or nivel $ un fanDin alto en los de menor nivel (!ue se de#e al
reuso de procedimientos).
Usa!ilidad
)eursticas de Xaco# 4ielsen para guiar el dise(o del sitio $ garantizar la usa#ilidad de
la Oe#:
7) Cisi#ilidad del estado del sistema.
7I
8) "orrespondencia entre el sistema $ el 1mundo real2.
:) "ontrol $ li#ertad del usuario.
;) st&ndares $ consistencia.
<) Prevencin del error.
B) -econocimiento mas !ue recuerdo.
G) 3le6i#ilidad $ eficiencia de uso.
H) 5ise(o austero $ minimalista.
I) .$uda al usuario a reconocer, diagnosticar $ recuperarse de los errores.
7M) .$uda $ documentacin.
Patrones de dise.o
5escri#e un pro#lema recurrente en nuestro am#iente $ el n'cleo de la solucin de ese
pro#lema, de modo !ue se puede re usar la solucin sin hacerlo dos veces igual
lementos esenciales de un patrn: 4om#re, pro#lema, solucin, consecuencias.
Patrn en o#*etos: 1descripciones de clases $ o#*etos !ue se comunican para resolver un
pro#lema de dise(o general en un conte6to particular.2
3irma: selectorEtipo de par&metrosEtipo de o#*eto. 9nterfaz: firmas m&s comportamiento.
"ohesin: 5e#era ser alta EE .coplamiento: 5e#era ser #a*o.
=uenas pr&cticas: 0Y00, 5-S, 4o So#redise(ar, /ell donZt asJ, 5//S, 9-, si algo se
tiene !ue romper, !ue se rompa lo antes posi#le, +aJe it worJErightEfast.
Patrones de "omportamiento:
7) ,emplate Met0od: define una serie de pasos en la superclase, pero los redefine
en las su#clases. Se define una herencia. Se arma una 1planilla2 en la superclase
$ los pe!ue(os cam#ios se tra#a*an en las su#clases. (*: densidad de figuras
geomtricas, con clase figura $ densidad redefinida para cada una)
8) +trateg": permite tener varios algoritmos e intercam#iar entre ellos cuando sea
necesario, seg'n el momento. ,n programa !ue realiza algo de distintas
maneras es candidato. so si, los o#*etos de#en ser polimrficos. +uchos
o#*etos chi!uitos cola#oran en vez de uno grande, responsa#ilidad distri#uida.
(*: la propina !ue cam#ia seg'n como esta el cliente).
:) +tate: el comportamiento de un o#*eto cam#ia seg'n su estado. "rea un o#*eto
por cada estado posi#le del o#*eto !ue lo llama. Permite al o#*eto alterar su
comportamiento seg'n el estado interno en el !ue est&. (*: tamagochi)
Patrones structurales :
;) Composite: permite construir o#*etos comple*os a partir de otros mas simples
$ similares entre si. structura en forma de &r#ol con interfaz com'n.
<) Decorator: permite a(adir din&micamente funcionalidad a un 0#*eto. Permite
no crear sucesivas clases !ue hereden de la primera a(adiendo nueva
funcionalidad, sino otras !ue la implementan $ asocian a la primera.
Patrones creacionales: Se enfrentan al pro#lema de la instanciacin. +uchas veces los
constructors no son suficientes. ncapsulan informacin de !ue clase usa el sistema.
B) -actor" met0od (creacional): 5efine una interfaz para crear o#*etos pero las
su#clases definen !ue clase instanciar. %e permite a una clase delegar su
instanciacin a sus su#clases. l 1!ue2 constru$o. (*: Pizzeras).
G) !stract factor": da interfaz para crear o#*etos de una misma familia. Sin
especificar la clase concreta a instanciar. .sla clases concretas, facilita cam#iar
el tipo de productos. Para agregar un nuevo tipo ha$ !ue cam#iar factor$.
8M
H) 1&ilder: separa el proceso de construccin de un o#*eto, de su representacin
interna, permitiendo a#straerse de la representacin interna. Fenera una solucin
igual para todos. 0 sea, creo un o#*eto en el !ue guardo 1o#*etitos2 a ser
ensam#lados. Se ocupa de 1como2 constru$o. (*: tours)
I) +ingleton: Se ocupa de clases !ue !uiero instanciar solo una vez.
7M) (&ll O!2ect: +odela la ausencia de algoritmo.
77) Protot"pe: ,sa una instancia de prototipo para especificar el tipo de producto a
crear $ crea nuevos usando esa foto. s como clonar.
78) nti patterns: 5ata o#*ect, Fod o#*ect.
)erencia vs. "omposicin: )erencia: st&tica, menos comple*Eo#*etos, -elacin entre
clases, menos cohesin.
"omposicin: cam#ia runtime, ma$or comple*idadEo#*etos, [ cohesin, D acoplamiento.
Metodologas 3giles
Presentan una manera no tradicional de construir grandes productos $ sistemas de
software. Se adaptan a los cam#ios, priorizan la persona $ no el proceso.
Proceso iterativo incremental, test continuo.
4P (E5treme Programming)
Feneralmente lo conducen pe!ue(os grupos con re!uerimientos vagos $ cam#iantes.
Pilares
Siempre pro#ar todo, cdigo sin prue#a es rechazado.
Programacin en pare*as en una misma P", programando $ de#uggeando.
Simpleza: hacer !ue las cosas sean f&ciles, no pensar en ma(ana.
"omunicacin con el cliente constante, historias detalladas.
Plan de iteracin: los desarrolladores !ue aceptan la tarea estiman la duracin.
-oles: Programador, cliente, tester, traJer, coach, consultor, gran *efe.
)istorias de usuarios: lo !ue !uiere el cliente !ue se haga.
+et&fora: lo mas parecido a la ar!uitectura, cada pro$ecto tiene una convencin de
nom#res a recordar.
Semana la#oral de ;M horas: si ha$ horas e6tra es se(al de !ue esta mal.
"odificacin est&ndar: no tiene !ue notarse !uien codific.
"digo colectivo: cual!uier programador puede tra#a*ar cual!uier parte.
+cr&m
tapas:
7) 9nicio:
a. Planeamiento: esta#lecer la visin, presupuesto, financiamiento $
#acJlog del producto. Se esta#lecen e!uipo de tra#a*o, herramientas $
fecha de entrega apro6imada.
#. .r!uitectura: conceptualizacin $ an&lisis. Se hace un dise(o de alto
nivel para actualizar modelos del dominio $ refle*ar el nuevo
conte6to del sistema. 5ise(adores $ ar!uitectos dividen el pro$ecto
#as&ndose en los tems del #acJlog.
8) 5esarrollo: Se divide en iteraciones (sprints), !ue es el proceso de adaptacin
a las varia#les !ue cam#ian con el entorno. ,n sprint puede durar de una
semana a un mes, $ cada uno a#arca las fases tradicionales del desarrollo del
software (re!uerimientos, an&lisis, dise(o, desarrollo $ entrega). s semi
catico, por lo cual no usa diagramas de Fantt. 5urante un sprint no se
pueden cam#iar los miem#ros del e!uipo ni introducirse cam#ios (estos se
87
hacen en el #acJlog). n cada sprint se planifica (reunin), desarrolla (con
las fases), envoltura (cerrar pa!uetes), revisin de riesgos $ a*ustes.
5urante un sprint se realizan reuniones diarias llamadas S"-,+, el o#*etivo
es !uitar impedimentos !ue sur*an, duran 7<Z, o#ligatorias. )a$ 1Fallinas2
(no pueden ha#lar, involucrados) $ 1"erdos2 (ha#lan, comprometidas).
:) "ierre: Se realiza cuando las varia#les de entorno est&n completas, $ el
desarrollo finalizado. documentacin final, testing $ lanzamiento.
s ideal para pro#lemas comple*os $ de am#ientes cam#iantes.
-oles: product owner, Scrum master, cliente, gerencia $ e!uipo S"-,+.
vita estancamientos, seguimiento del e!uipo $ del pro$ecto, el SO incrementa su
funcionalidad en cada sprint. "ontrola cam#ios en el entorno $ el pro$ecto me*ora aun
con ellos. l cliente o#tiene feed#acJ frecuente.
5esventa*as: delegacin de autoridad, resistencia al cam#io.
.ne6o:
Carta estr&ct&rada
5iagrama *er&r!uico de mdulos. Se #asa en la alta cohesin $ #a*o acoplamiento, lo
!ue le da reusa#ilidad. Se clasifican en:
3uncin:
o 0perativos: completan tareas.
o "oordinacin: controlan la e*ecucin de los operativos.
,so (Solo para los operativos):
o /erminales: producen resultado final.
o 9ntermedios: el coordinador se lo pasa a otro.
/iempo de procesamiento:
o 0nDline: el proceso se realiza de forma continua.
o 0ffDline: se corta temporalmente a la espera de respuesta.
88