Vous êtes sur la page 1sur 29

UNIVERSIDADTECNOLOGICAEMILIANOZAPATA

TecnologasdelaInformacinylaComunicacin.
rea:SistemasInformticos

Apuntes
ANLISISYDISEOENSISTEMASII

Alumno:
IvnJessSoteloColn

4A





AnlisisydiseodeSistemasII
Prof.:Lic.BernardoHuicocheaNaranjo

Cuatrimestre:SeptiembreDiciembre

SkycharANLISISYDISEO

ndice
PARCIALI..................................................................................................................................................4
ELPROCESOPERSONALDESOFTWARE(PSP)...........................................................................................................4
1.1LoselementosdelPSP..........................................................................................................................4
PSP0.MEDICINPERSONAL..................................................................................................................................6
PSP1.PLANIFICACINPERSONAL..........................................................................................................................6
PSP2.CALIDADPERSONAL.....................................................................................................................................6
PSP3.CCLICOPERSONAL.......................................................................................................................................6
1.2ElPSP0.................................................................................................................................................7
1.3CaractersticasdelPSP0......................................................................................................................8
1.4EsquemadelProcesoinicial.................................................................................................................8
LostiposestndardedefectoenPSP.....................................................................................................................9
INTRODUCCINALAINGENIERADESOFTWARE(IS)................................................................................................10
Categoras................................................................................................................................................10
Divisin....................................................................................................................................................10
Sistemasenlnea:.................................................................................................................................................10
Sistemasdetiemporeal:......................................................................................................................................11
Sistemasdeapoyoadecisiones:..........................................................................................................................11
Sistemasbasadosenelconocimiento:.................................................................................................................11
QueesSoftware?...................................................................................................................................11
ProductosdeSoftware.............................................................................................................................11
CaractersticasdelSoftware:...................................................................................................................12
IngenieradeSW......................................................................................................................................12
Software:.................................................................................................................................................12
ProductosdeSW......................................................................................................................................12
LACRISISDELSOFTWARE........................................................................................................................13
Sntomas:..............................................................................................................................................................13
MITOSDELSOFTWARE............................................................................................................................13
MitosdelSWCliente.........................................................................................................................................13
MitosdelSWDesarrolladores...........................................................................................................................14
DEFINICIONDEINGENIERIADESOFTWARE.............................................................................................14
REASDELAINGENIERADELSOFTWARE...............................................................................................14
OBJETIVODELAINGENIERADESOFTWARE...........................................................................................15
ComponentesdeunProductoSW...........................................................................................................16
MODELOSDEDESARROLLODESW..........................................................................................................16
ElciclodevidadelSW..........................................................................................................................................16
LadasededesarrollodelciclodevidadelSW.....................................................................................................17
ModelodeCascadaociclodevidaclsico:..........................................................................................................17
ModeloEvolutivo.................................................................................................................................................18
Modeloprototipadoodeprototipos...................................................................................................................18
ModeloBasadoenlareutilizacin........................................................................................................................19
Modelodeprocesoenespiral..............................................................................................................................19
RESPONSABILIDADPROFESIONAL...........................................................................................................19
Aspectosderesponsabilidadprofesional.............................................................................................................20
PrincipiosCdigosdetica................................................................................................................................20

SkycharANLISISYDISEO

PARCIALII...............................................................................................................................................21
LAPROGRAMACINORIENTADAAOBJETOS............................................................................................................21
QUESUNOBJETO?........................................................................................................................................22
CONCEPTOSDELAORIENTACINDEOBJETOS:........................................................................................................22
Clase.........................................................................................................................................................22
Instancia..................................................................................................................................................22
Constructor..............................................................................................................................................22
Abstraccin:.............................................................................................................................................23
Herencia...................................................................................................................................................23
Encapsulamiento:....................................................................................................................................24
Relacionesentreobjetos..........................................................................................................................24
Polimorfismo............................................................................................................................................25
Envidemensajes....................................................................................................................................25
Ocultamiento:..........................................................................................................................................25
Concurrencia:...........................................................................................................................................25
Persistencia:.............................................................................................................................................25
Modularidad:...........................................................................................................................................25
INTRODUCCINALUML...............................................................................................................................25
Extensiones:.............................................................................................................................................26
Estereotipos:............................................................................................................................................26
Valoresetiquetados.................................................................................................................................26
Restricciones:...........................................................................................................................................26
DIAGRAMASUML:...........................................................................................................................................26
Undiagramadeactividades:...................................................................................................................27
Diagramasdeinteraccin:.......................................................................................................................28
Undiagramadesecuencia.......................................................................................................................28
Diagramadecolaboracin:.....................................................................................................................28
Diagramasdecasodeuso:......................................................................................................................28
Actores:....................................................................................................................................................28
FormatodeCasodeuso..........................................................................................................................29

SkycharANLISISYDISEO

PARCIALI

INTRODUCCIN

En la actualidad para muchas organizaciones, los sistemas de informacin basados en


computadoras son el corazn de las actividades cotidianas y objeto de gran consideracin en la
toma de decisiones, las empresas consideran con muchos cuidados las capacidades de sus
sistemasdeinformacincuandodecideningresaronoennuevosmercadosocuandoplaneanla
respuesta que darn a la competencia. El anlisis y diseo de sistemas es la investigacin de la
empresa en su totalidad en la cual se determina el funcionamiento de la misma, lo bueno y lo
malo,tambinsuhistoria,ademsdelaspublicacionesdelramoalcualsededica.

Por lo que se necesita tener toda la informacin completa, confiable y verdadera para tomar
decisionescorrectamente.

Todo esto con la finalidad de determinar los errores que pudiese haber en la empresa para as
posteriormenterealizarunplan,paracambiarloqueseesthaciendomal.
Ademsderealizarcambiosenlaempresaparapoderhacereficienteeltrabajodelosempleados
y que puedan producir ms, al mismo tiempo que se sientan ms y mejor integrados a la
organizacin.

Enestemanualsetratadepresentarunadefinicinprecisadeloqueesorepresentaunsistema
detrabajoqueannoexiste,yaquelosdiferentesautoresyestudiososdelamaterianosehan
puestodeacuerdoycadaunodeelloenfocaelproblema.

ElProcesoPersonaldeSoftware(PSP)
1.1LoselementosdelPSP.
La Ingeniera de Software es una disciplina dentro de las Ciencias de la computacin, cuyo
principalobjetivoeselofrecermtodos,tcnicasyherramientasquepermitanlaproduccinde
softwaredecalidad.Aunquestanoesunadisciplinamaduraentodasuextensin,actualmente
existenvariasmetodologas,tcnicasyherramientas,quepuedenutilizarsepararealizardemejor
forma,lasactividadesasociadasalprocesodedesarrollodelsoftware.

ElPersonalSoftwareProcess,conocidoporsussiglascomoPSP,esunametodologadereciente
creacin, proveniente del Instituto de Ingeniera del Software (SEI) y desarrollado por Watts
Humphrey (creador a su vez del CMM), presenta tcnicas y mtodos para definir y gestionar un
procesopersonaldesoftware.ApesardequeunmodeloCMMesmuyinteresantedadoquese
aplicageneralmenteagrandesempresasdesoftware,elPSPesunmodelomassimple,orientado
parapequeasempresasoparaunnicoindividuo.

PSPesunaalternativadirigidaalosingenierosdesistemas,quelespermitemejorarlaformaenla
que construyen software. Considerando aspectos como la planeacin, calidad, estimacin de
costos y productividad, PSP es una metodologa que vale la pena revisar cuando el ingeniero de
software est interesado en aumentar la calidad de los productos que desarrolla dentro de un
contextodetrabajoindividual.
SkycharANLISISYDISEO

Atendiendoalapremisadequeexisteunafuerterelacinentrelashabilidadesdelosingenieros
desoftwareylacalidaddelosproductosquedesarrollan,lasactividadesestablecidasenPSPestn
orientadasalconocimiento,administracinymejoradesushabilidadesalconstruirprogramas.

EnPSPtodaslastareasyactividadesqueelingenierodesoftwaredeberealizarduranteelproceso
de desarrollo de un producto de software, estn puntualmente definidas en un conjunto de
documentosconocidoscomoscripts.

Los scripts son el punto medular de PSP, por lo que se hace mucho nfasis en que deben ser
seguidosenformadisciplinada,yaquedeellodependerelxitodelamejoraquesebusca.Gran
partedelastareasyactividadesdefinidasenlosscriptsgenerarensurealizacinunconjuntode
datos, fundamentalmente de carcter estadstico. La aplicacin de PSP en varios procesos de
desarrollo,yelanlisisdelainformacinestadsticageneradaencadaunodestos,permitenal
ingenierodesoftwareidentificar,tantosusfortalezascomosusdebilidades,ycreceratravsde
unprocesodeautoaprendizajeyautomejora.

Losscriptsseorganizanencuatroniveles,identificadosdel0al3,atendindoseencadanivelun
conjuntodeaspectosamejorardelprocesodedesarrollodesoftware.Alprimernivelseleconoce
como 0 o de medicin personal, al segundo como nivel 1 o de planeacin personal, al tercero,
comonivel2odecalidadpersonal,yalcuartocomonivel3occlicopersonal.Cadaunodeestos
niveles,conexcepcindel3,tieneunaversinquelosextiende,introduciendotareasyactividades
para un mejor manejo de los aspectos de inters en nivel, o bien para incluir nuevos aspectos,
comolomuestralafigura1,dondecadaunodelosnivelesextiendelosaspectosconsideradosen
elnivelinmediatoanterior.


Figura1.ElementosyarquitecturaprincipaldelPSP.

Una de las razones de esta clasificacin puede ser el que PSP es una metodologa de mejora
basadaendatosestadsticos,loscualesdebensercuidadosamenterecabadosporelingenierode
SkycharANLISISYDISEO

software;elaumentogradualdelacantidaddedatosquedeberecolectarelingenierointroduce,
porconsiguiente,elcambioensumaneradetrabajodeunamanerapaulatina.Serecomiendaun
usoincrementaldePSP,iniciandoconelnivelmsbajoduranteunprimerproyectodedesarrollo
y, en proyectos siguientes, ascendiendo a niveles superiores. Los scripts no pueden utilizarse en
formaseparadaodesordenada.

PSP0.MEDICINPERSONAL
ElProcesoPersonaldeSoftware(PSP)
Losaspectosdeintersenestenivelserelacionanconlaestimacindeltiempoparadesarrollar
un producto de software y la identificacin, clasificacin y manejo de los defectos producidos
duranteelprocesodedesarrollo.Losdatosrecopiladosmediantelaaplicacindelosscriptssirven
debaseparalarealizacindeestimacionesmsrealesenprocesosfuturos.PSP0.1esunnivelque
extiende y complementa a PSP 0, a travs del establecimiento de estndares de decodificacin
orientados a mejorar las estimaciones de tamao, as como la consideracin de propuestas de
mejoraalnivelporpartedelingenierodesoftware.

PSP1.PLANIFICACINPERSONAL
Utiliza informacin recabada en procesos anteriores, se concentra en el uso de un mtodo de
naturaleza estadstica denominado PROBE (PROxy Based Estimating), para la estimacin del
tamaoytiemponecesarioparaeldesarrollodeproductosdesoftware.Elobjetivoenestenivel
esqueelingenierodesoftwareadquieraexperienciaymejoresusestimacionessobretamaosy
tiempos.

ElPSP1.1esunnivelquecomplementaaPSP1,introduciendoelusodemtodosyherramientas
paralaorganizacindelastareasdelprocesodedesarrollo.

PSP2.CALIDADPERSONAL
El aspecto de inters en PSP 2 es la calidad. La calidad en PSP, es un aspecto fuertemente
relacionado con la cantidad de defectos que el producto de software contiene. Atendiendo a la
premisaanterior,enestenivelseintroducenlasinspeccionesenlasfasesdediseoycodificacin,
comounmecanismoparaaumentarlacalidaddelosproductos.

EnPSP2.1seintroduceelusodeespecificacionesdediseo.

PSP3.CCLICOPERSONAL
En este nivel se introducen algunos mtodos aplicables al proceso de desarrollo de software,
dentrodeunenfoquedeproyectosagranescala,perosinlidiarconproblemasdecomunicaciny
coordinacindelosequiposdetrabajo.Elcambioqueharealizadoelingenierodesoftwareenla
formaderealizarsusactividadeshasidodeformaindividual.Paraproyectosdebajacomplejidad,
PSP3 introduce los lineamientos iniciales para considerar proyectos de mayor complejidad y
dentrodeunentornodedesarrollointegradopormsdeundesarrollador.

De manera general el PSP se puede considerar como un framework para auxiliar a estimar y
planearsustareas,acompaarsudesarrolloenrelacinaloplaneadoymejorarlacalidaddelos
productosfinales.Paraelloutilizatrestiposdemedida:esfuerzo,tamaoydefectos.

El objetivo del PSP es auxiliar al desarrollador de software en su trabajo, conocer sus talentos y
mejorar sus habilidades; as como ofrecer mtricas y anlisis de mtricas; e introducir
gradualmentetcnicasdelaingenieradesoftware.
SkycharANLISISYDISEO

ElPSPesunaalternativa,delasmuchasquehansurgido,paramejorarelprocesodedesarrollode
software y ms que clasificar un conjunto de sentencias como ventajas o desventajas, a
continuacinsecitanalgunascaractersticas,dejandoacriteriolaclasificacindelasmismas:

PSP es una metodologa basada en estimacin. La estimacin permite saber cundo y


cmosedesarrollanlastareasdeunproceso,porloquepodracitarsecomounaspecto
importantedeestametodologaelestarbasadaenmtricasyestimaciones.

Lainformacindelasmtricasyestimacionesseutilizaparaevaluarymejorarprocesos
futuros.PSPpartedelapremisaque,sielingenierodesoftwareconocesusfortalezasy
debilidades, puede establecer las acciones necesarias para erradicar o explotar los
aspectosidentificadosenlaformaenquedesarrollasoftware.

Aunquelomencionadoenelpuntoanteriorpodrasonarbastanteatractivo,laformade
llegar a ese autoconocimiento puede resultar tediosa y, en el peor de los casos, una
pesadillaparaeldesarrollador.Salvomuypocasexcepciones,losingenierosdesoftware
nuncarealizanprocedimientosformalesparaconocerlaformaenquetrabajan,nosaben
con exactitud cuntas lneas de cdigo generan por hora, cunto tiempo invierten al
corregirunerror,cuntotiempoinviertenenpruebas,etctera.

Los pasos de registro de informacin a detalle en el nivel de medicin pueden resultar
frustrantescuandosetienepresindetiempo.

En los scripts de PSP no se incluyen tareas y actividades para la etapa de anlisis de


requerimientos. Siempre se parte de una definicin de requerimientos que no va a
cambiar.

1.2ElPSP0.
El nivel de Medicin de Personal (PSP 0) es un proceso sencillo, definido y personal, utiliza los
mtodosactualesdediseoydesarrollo;recogedatosdeltrabajoarealizartalescomoeltiempo
gastadoporcadafaseylosdefectosencontradosencompilacinypruebas,ademsproporciona
uninformeresumen(verfigura2).Estoesconseguidoatravsdelusodeformulariosadecuados.
El nivel PSP0.1 incluye el uso de un estndar de codificacin, de medidas y de propuestas de
mejoramiento de proceso. El PSP 0 y PSP 0.1 establecen un ponto de partida para una
comprensindelprocesodesoftwareyconsecuentemente,unabasesobrelacualpromoverlas
mejoras.

Herramientas:Suministranunsoporteautomticoparalosmtodosyprocesos.
Proceso:Conjuntodepasosqueayudanaobtenerelresultadoesperado.
Mtodos:Indicancmoconstruirtcnicamenteelsoftware

SkycharANLISISYDISEO


Figura2.ElflujodelprocesodelPSP.

1.3CaractersticasdelPSP0.
DentrodelascaractersticasprincipalesdelPSP0podemosencontrarlassiguientes:
PSP 0 usa el proceso existente para desarrollar el software. Si no lo hay se proporciona
uno.
PSP0introducealgunasmtricasbsicascomo:
Tiempos.
Defectosytipologa.
PSP0.1aade:
La propuesta de mejora de procesos, para informar de los problemas y
experienciasconelprocesoyrecogesugerenciasdemejora.
Un estndar de codificacin para poder medir con exactitud el tamao del
softwareyasegurarsucalidad.

AdemselPSP0seconformadelossiguienteselementos:
Unguindeproceso.
Unformularioresumendeplanproyecto.
Unregistrotiempo.
Unregistrodedefectos.
Unestndardetiposdefecto.

1.4EsquemadelProcesoinicial.
El esquema del proceso inicial o simplemente guin de proceso contempla tres aspectos
principales,comoson:

Planificacin.Dondeseestimatiempodedesarrollo.
Desarrollo.Sedesarrollaelproductoutilizandolosmtodosactuales.
Postmortem. Se completa el resumen del plan proyecto, con los tiempos gastados y defectos
encontradoseinyectadosencadafase.
SkycharANLISISYDISEO

Esteesquemasepuederesumirdemanerageneralenlasiguientetabla.
Nmero Propsito Guaseneldesarrollodeprogramasaniveldemdulo
Fase
Entradas Descripcindelproblema.
Necesarias FormulariodeResumendelPlandeProyectoPSP0.
TablasdeRegistrodeTiemposyDefectos.
EstndardeTiposdeDefectos.
Cronmetro(opcional).
1 Planificacin Produciruobtenerlosrequisitos.
EstimarlasLOC(LineOfCode)necesarias.
Estimareltiempodedesarrollonecesario.
Indicar los datos del plan en el Resumen del Plan de
Proyecto.
CompletarelLogdeRegistrodeTiempos.
2 Desarrollo Disearelprograma
Implementareldiseo.
Compilar el programa y corregir todos los defectos
encontrados.
CompletarlaTabladeRegistrodeTiempos.
3 Postmortem Completar el Resumen del Plan de Proyecto con los datos actuales
detiempo,defectos,ytamao.
Criteriosdesalida Unprogramaprobado.
UnResumendePlandeProyectosconlosdatosestimadosy
losactuales.
LasTablasdeRegistrodeTiemposyDefectosrellenos.

LostiposestndardedefectoenPSPson:

Tipo Nombre Descripcin


10 Documentacin Comentarios,mensajes
20 Sintaxis Ortografa,puntuacin,tipos,formatosdeinstruccin
30 Construccin Gestindecambios,libreras,controldeversiones
40 Asignacin Declaracin,nombresduplicados,mbito,limites
50 Interfaz Llamadasyreferenciasarutinas,I/O,formatos
60 Comprobacin Mensajeserror,comprobacionesinadecuadas
70 Datos Estructura,contenido
80 Funciones Lgica,punteros,bucles,recursin,calculo,defectosenfunciones
90 Sistema Configuracin,tiempos,memoria
100 Entorno Diseo,compile,pruebasyproblemasdelsistemadesoporte

SkycharANLISISYDISEO

IntroduccinalaIngenieradeSoftware(IS)
Categoras

Unadefinicinbsicadesistemaeslasiguiente:
Grupodeelementosinterdependientesoqueinteractanregularmenteformandountodo.

Existendoscategorasbsicasenlaclasificacindesistemas:
1. Sistemasnaturales.
2. Sistemashechosporelhombre.

En lo que respecta a los sistemas hechos por el hombre existe una gran diversidad de sistemas
construidos, organizados y mantenidos por humanos, tales como: sistemas sociales, sistemas de
transporte,sistemasdecomunicacin,sistemasdemanufactura,sistemasfinancieros,etctera.

En la actualidad, la mayora de estos sistemas incluyen las computadoras pero es importante


sealar que dichos sistemas existan antes de que hubiera computadoras, de hecho, algunos
sistemas continan por completo sin computarizar y podran permanecer as durante muchas
dcadasms.Otroscontienenalacomputadoracomocomponente,perotambinincluyenunoo
mscomponentesnocomputarizados(omanuales).

Los sistemas automatizados son sistemas hechos por el hombre que interactan con o son
controlados por una o ms computadoras. Aunque hay diferentes tipos de sistemas
automatizados,todostiendenatenercomponentesencomncomo:

El hardware de la computadora: los procesadores, los discos, terminales, impresora,


unidadesdecintamagntica,etctera.

El software de la computadora: Los programas de sistemas tales como sistemas


operativos, sistemas de base de datos, programas de control de telecomunicaciones,
etctera.

Las personas: los que operan el sistema, los que proveen su material de entrada y
consumensumaterialdesalida,ylosqueproveenactividadesdeprocesamientomanual
enunsistema.

Losdatos:lainformacinqueelsistemamaneja.

Losprocedimientos:laspolticasformaleseinstruccionesdeoperacindelsistema.

Divisin

Unadivisincategricadelossistemasautomatizadoseslasiguiente:

Sistemasenlnea:esaquelqueaceptamaterialdeentradadirectamentedelreadondesecreo.
Tambinesunsistemaenelqueelmaterialdesalida,oresultadodelacomputacin,sedevuelve
directamenteadondeesrequerido.

SkycharANLISISYDISEO

Sistemas de tiempo real: puede definirse como aquel que controla un ambiente recibiendo
datos, procesndolos y devolvindolos con la suficiente rapidez como para influir en dicho
ambienteenesemomento.

Sistemas de apoyo a decisiones: Estos sistemas computacionales no toman decisiones por si


mismos, sino ayudan a los administradores, y a otros profesionistas "trabajadores del
conocimiento"deunaorganizacinatomardecisionesinteligentesydocumentadasacercadelos
diversosaspectosdelaoperacin.

Sistemasbasadosenelconocimiento:Estossistemascontienengrandescantidadesdediversos
conocimientosqueempleaneneldesempeodeunatareadada.Lossistemasexpertossonuna
especie de sistemas basados en el conocimiento, aunque ambos trminos a menudo se utilizan
indistintamente.

Existen algunos principios generales que son de inters particular para quienes crean sistemas
automatizadosdeinformacin,eincluyenlossiguientes:

Entre ms especializado sea el sistema, menos capaz es de adaptarse a circunstancias


diferentes.
Cuantomayorseaelsistemamayoreselnmerodesusrecursosquedebendedicarsea
sumantenimientodiario.
Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse en
sistemasmenores.
Lossistemascrecen.

Estadstica: Es una ciencia con base a la temtica de coleccin, anlisis e interpretacin de los
datosquebuscaexplicarcondicionesreguilaresenfenmenosdetipoaleatorio.

Manuales:
ManualTcnico
ManualUsuario/Operacin
ManualdeCliente/Administrativo

QueesSoftware?
El software son instrucciones (programas) que cuando se ejecutan proporcionan la
Funcinyelrendimientodeseado.

Estructuras de datos que permite a los programas manipular adecuadamente la


informacin.

Documentosquedescribenlaoperacinyelusodeprogramas.

ProductosdeSoftware
ProductosGenricos:Sonproducidosporunaorganizacinparaservendidosalmercado.
Productos hechos a medida: Sistemas que son desarrollados bajo pedido a un
desarrolladorespecifico.

SkycharANLISISYDISEO

La mayor parte del gasto del software es en productos genricos, pero hay mas esfuerzo en el
desarrollodelossistemashechosamedida.

CaractersticasdelSoftware:

Mantenibles:Debeserposiblequeelsoftwareevolucioneyquesigacumpliendoconsus
especificaciones.

Confiabilidad: El software no debe causar econmicos en el caso de fallos. Apoya


eficientementelatomadedecisiones.

Eficiencia:Elsoftwarenodebedesperdiciarlosrecursosdelsistema.

Utilizacin adecuada: El software debe contar con una interfaz de usuario adecuada y
solidadocumentacin.

IngenieradeSW
Eslaaplicacindelaingenieraenelprocesodesoftware.
Incluyelaaplicacinprcticadelconocimientocientficoeneldiseoyconstruccindeprogramas
para computadoras y la documentacin asociada requerida para desarrollarlos, operarlos y
mantenerlos.

Software:
Sedefinecomoaquellosprogramas,procedimientos,reglasydocumentacinposibleasociadacon
lacomputacin.

La ingeniera de software surge como una disciplina a fines de la dcada de los 60s, cuando se
hacen presente los graves problemas existentes en la produccin y sobre todo en el
mantenimientodesoftware,conocidacomoLacrisisdelsoftware.Laspracticasartesanalesde
programacinylanuladocumentacinqueseutilizabaeneseentonceshizocrisis,ydeterminaron
quesepensaraenelsoftwarecomounproblema quenecesariamente deberaserabordadode
esta sistemtica. El modelo bsico de esta sistematizacin corresponde a una variacin de un
modelodesarrolladoenladcadadelostreintaenlosLaboratoriosBell,mtodoqueenelmbito
delsoftwareseconocecomoelciclodevidatradicional.

Laideadetrsdeunproyectodeciclodevidatradicionalconsisteenunaplanificacincuidadosay
aproximaciones sistemticas al desarrollo de software, buscando con ello controlar sus costos.
Adems,conellosebuscadividireldesarrollodesoftwareenetapas,conelobjetivodehacerms
fcillaconstruccindesoftwaremscomplejo,dondecadaetaparequierequelainmediatamente
anteriorhayasidocompletada.

ProductosdeSW
Esbsico,sisequiereprofundizarenlaIngenieradeSoftware,determinarloqueseentiendepor
software.Pero,muyanuestropesar,aquellonoestantrivialcomosecree.Claro,esfcilpensar
quesoftwareesunprogramaquehacequeunacomputadoracumplaunatarea,cualquieraque
esta sea. Pero, este programa tiene mltiples dimensiones, por ejemplo, es cdigo de algn
lenguaje de programacin que puede ser intervenido por un programador, pero tambin es un
procesoqueseestejecutandoyquees"manipulado"porunusuarioysteinteractaconla
travsdeunainterfaz(lapantalla,loslistados)dehechoestoesparaelusuario,elsoftware.
SkychharANNLISISYDIISEO

waresedesarrollabayutilizabaporlamismapersonauorganizaacin.Lamism
Lamayyoradelsoftw ma
naloescriba,loejecutabaysifallabalo
person odepuraba.
Debido
o a que la movilidad
m en el trabajo era
e baja, los ejecutivos estaban segurros de que esa
e
naestaraallcuandoseen
person ncontraraalg nerror.

LACRISISDELSOFTWARE

Sntommas:
BajaCalidad ddelsoftware.
Tiempoyprresupuestoexcedido.
Confiabilidaadcuestionab ble.
Altosreque erimientosdelpersonalparadesarrolloymantenimiiento.

El 75% ntencin. Solo el 25% de los recursos se


% de los recurrsos informtticos se destiinan a la man
destinaaaldesarrollo odenuevasaaplicaciones.

Nosevvaloranlosbe eneficiosdeuunacorrectaiimplementacindeSoftwaare.
LosclientessquierenelSo oftwareparaayer.
Notienentiempoparad darinformaci n.
Cambianco onstantementtesusrequerimientos.
Paraquean nlisis,diseo
o,documentaacin,sololessinteresalaaplicacin.

SDELSOFTW
MITOS WARE

MitosdelSWClieente.

o Mitto: Una decclaracin general de los objetivos
o es suficiente paara comenzarr a
escribirlosprogramas,podem mosdarlosdetallesmasaadelante.
o Reaalidad: Una mala
m definicin inicial es la principal causa del trrabajo intil en
softtware. Es essencial una descripcin formal y detallada del mbito de la
info
ormacin. Ess necesario una
u exhaustiiva comunicaacin entre el cliente y el
anaalista.

o Mitto: Los requ uisitos del proyecto cam mbian continu uamente, pero los cambios
pueedenacomod darsefcilmen nteyaqueelsoftwareesfflexible.
o Reaalidad:Esverrdadquelos requisitosdeelsoftwarecaambian,pero oelimpactod del
cam
mbiovariaseggnenelmom mentoqueseepresenten.
Definici n:Bajoimpaacto
Desarrollo:Altoimpaacto
Despussdelaentregga:CriticoImpacto.

SkychharANNLISISYDIISEO

MitosdelSWDessarrolladorees

o Mitto: Una vez que escribim mos el progrrama y hacemos que fun ncione, nuesttro
trab
bajohatermiinado.
o Reaalidad: Cuand do ms prontto se comien
nce a escribirr cdigo, mass se tardara en
term
minarlo.Entrreel50%yell70%detodo oelesfuerzo dedicadoau unprograma se
realizaradespusdequeselaahayaentreggadoalclienteporprimeraavez.
o Mitto:LonicoqueseentreggaalfinaldellProyectoeselprogramafuncionando.
o Reaalidad: Unprrogramaque funciona es solounaparrtedeunaco onfiguracind del
softtware que in
ncluye prograamas, docummentos y dato mentacin es la
os. La docum
bassedeundesarrolloy,loquueesmsimp portante,prooporcionaguasparalatarrea
demantenimien ntodelsoftwaare.

DEFINNICIONDEIN NGENIERIAD DESOFTWA ARE

Es una discciplina que offrece mtodo os y tcnicass para


desarrollar y mantenerr Software de d Calidad ell cual Anllisisdel
tiene comoo objetivo sattisfacer los reequerimiento os del problema
Cliente.

Es la aplicacin dee un enfo oque sistem mtico


disciplinado
oycuantificaableal:Desarrrollo,Operacciny Dise
odela
Mantencin ndelSoftware. Sollucin
DefiniccindelaIEEEE1

La ingenierra de Softw ware es unaa disciplina de d la


Ingeniera que
q conciern ne a todos lo os aspectos de la
produccindelsoftwaree.
Implemmentacin n
delaSSolucin

REASSDELAINGENIERADE ELSOFTWAR RE
SegnestndardellaIEEElaIngeenieradeSofftwaresediviideen4grand
desreas.


1
IEEE:TTheInstituteofElectricaland
dElectronicsEngineers.(InstitutodeIngenierosElctricosyElectrnico
os).
Esunaaasociacintcnicoprofesio onalmundialdedicadaalaesstandarizacindeTIentreotrascosas.
SkychharANNLISISYDIISEO

TIVODELAI
OBJET INGENIERA
ADESOFTW
WARE

Esprod
ducirSoftwarre


Confiable: ATiempo: Commpleto:
Apoya eficienteme
ente con la Cumpleconnlasfechasy plazos Cueenta con una buen na
tomad
dedecisiones. establecidos. documentacin. Cumple co on
los r
requerimiento
os
estaablecidos.
SkycharANLISISYDISEO

ComponentesdeunProductoSW

MODELOSDEDESARROLLODESW

ElciclodevidadelSW

Development Use

Modification

Modificacin: Para adaptarse a los cambios del entorno (en otros productos se conoce como
reparacinomantenimiento).

SkycharANLISISYDISEO

LadasededesarrollodelciclodevidadelSW

Analysis

Design

Implementation

Testing

ModelodeCascadaociclodevidaclsico:

Definicinde
requerimientos

Diseodesistemay
software

Implementacinypruebas
deunidades

Integracinypruebasde
sistema

Operaciny
mantenimiento

Elmodelodecascadasedefinecomounasecuenciadeactividadesaserseguidasenorden.Este
modelotuvogranaceptacinenlacomunidaddecontratistasgubernamentalesestadounidenses,
yaquestosrecibansuspagosdelgobiernoenbaseaentregasbasadasenhorariospredefinidos.

Eldesarrollodesoftwareimplicabaunasecuenciadeactividadesarealizarseycuyoseguimiento
eraverificarquecadaactividadhayasidocompletada.Laejecucindelmodeloeramuylineal,por
locualelmodelofuesencilloyatractivo;dondeseespecificabalasactividadesparaluegohacerlas
de principio a fin. Se consideraba que una vez terminada una actividad se continuaba con la
siguiente.Fueutilizadoendesarrollosbiencomprendidos.
SkycharANLISISYDISEO

ModeloEvolutivo


Especificacin Versininicial


Versiones
Descripcindelsistema
Desarrollo intermedias
(Bosquejodeladescripcin)



Validacin Versinfinal



Enestemodelolaespecificacinyvalidacinestnintercaladas.
En este tipo de modelo los sistemas son pobremente especificados, debidos a que los
requerimientos fueron especificados por personas que no va a usar el software, pero dentro de
sushabilidadesespecialesseencuentraelpoderobtenerlainformacinqueesrequeridaparael
desarrollodelsoftware.

Entresuscaractersticasgeneralespodemostener:
Pocavisibilidadenelproceso.
Lossistemasestnpobrementeespecificados.
Serequierenhabilidadesespeciales.
Aplicabilidadparasistemasinteractivospequeosomedianos.

Modeloprototipadoodeprototipos.

En el modelo prototipado, el cliente ve resultados de manera rpida.. Consiste en capturar un
conjunto inicial de necesidades e implementarlas rpidamente, con la intencin declarada de
expandir y refinarlas lateramente, al ir aumentando la comprensin en el sistema y de quien lo
desarrolla.

Enladefinicindelsistemaevolutivoygraduar,ofreceunaatractivaalternativapracticablealos
mtodos para tratar mejor la incertidumbre, la ambigedad y la volubilidad de los proyectos
reales.Enelmodeloprototipado,elclienteveresultadosdemanerarpida.

Dentrodelenfoquedeprototipossepretendequeelmodeloseaoperante,esdecir,unacoleccin
de programas de computadora que simulan algunas o todas las funciones que el usuario desea.
Paralograrloanteriorseutilizanlassiguientesherramientasdesoftware:

SkychharANNLISISYDIISEO

Undiccionaariodedatosintegrado.
Ungenerad dordepantalllas.
Ungenerad dordereporteesnoguiadoporprocedim mientos.
Unlenguaje edeprogramacindecuartageneraci n.
Unlenguaje edeconsultasnoguiadop porprocedimientos.
mediospod derososdeaddministracindebaseded datos.
Elmoddelodeprotootiposcomien nzaconunaaactividaddessondeo;deesstosigueunaadeterminaciin
deselproyectoessunbuencanndidatoparau unenfoqued deprototipos.Losbuenoscandidatossson
aquelloosquetienen
nlassiguienteescaracterstiicas:
El usuario no
n puede o no
n est dispu uesto a exam
minar modelos abstractos en papel, tales
comodiagramasdeflujo odedatos.
Elusuarion nopuedeono oestdispuestoaarticulaarsusrequerimientosden ningunaformaay
slosepuedendetermin narsusrequeerimientosmeedianteunprrocesodetan nteo,oensayo oy
error.
Setienela intencinde queelsistem maseaenlnneayconopeeracintotal porlapantalla,
encontrapoosicinconlo
ossistemasdeeedicin,acttualizacinyrreportesoperradosporlotee.
Elsisteman norequierelaaespecificaciindegrandeescantidadessdedetalles algortmicos,,ni
de muchas especificacioones de proccesos para deescribir los algoritmos co
on los cuales se
obtienenre
esultados.

ModelloBasadoen nlareutilizaacin.

Enesteetipodemodelo,elsistem maesensam mbladoapartiirdecompon nentesexistentes,elmodeelo


reduceetiemposyco ostosdedesaarrolloycontiieneprincipio
os.
Princip
piosdelareuttilizacin:
Existeensimilitudesentredistintossistemasdeunmismo odominiode aplicacin.
Elsofftwarepuedeerepresentarrsecomounacombinacin ndemdulos.
Lossistemasnuevvossepueden ncaracterizarrpordiferencciasrespectoalosantiguos.

Modellodeproceso oenespiral

El mod
delo de espiral contemplaa que el desaarrollo
de sistemas es un proceso de cam mbios
progreesivos. Un sistema normalmente
n e se
desarroolla mediantee cambios enn la especificcacin
de la versin an nterior del sistema
s quee son
incorpoorados a nuevas
n versiones, dondee un
cambioo se conocce como un u delta en e la
especifficacindere
equisitosoveersin.

RESPO ONSABILIDA ADPROFESIONAL


La ingeniera de Softtware con
nlleva
responnsabilidades ms amplias que solo la
aplicaccindehabilid
dadestcnicaas.

SkycharANLISISYDISEO

Losingenierosdesoftwaredebencomportarsedeunamanerahonestayticamenteresponsable
si van a ser respetados como profesionales. Comportamiento tico es mas que simplemente
cumplirconlasleyes.

Aspectosderesponsabilidadprofesional
Confidencialidad: Los ingenieros deberan normalmente respetar la confidencialidad de
sus empleadores o clientes, aun cuando no se haya firmado un acuerdo de
responsabilidadformal.
Competencia: Los ingenieros no deberan atribuirse niveles de competencia que no les
corresponde.Nodeberanaceptarconscientementetrabajoqueexcedasuscompetencias.
Derechos de propiedad intelectual: Los ingenieros debern estar al tiempo de leyes
locales, que gobiernan el uso de propiedades intelectual; deberan asegurarse que la
propiedadintelectualdeempleadoresyclientesseaprotegida.
Mal uso de computadoras: Ingenieros de software no debern utilizar los equipos de la
gente.Elmalusodeequiposvariadesdeunorelativamenteinofensivo(porejemplo:Jugar
enequiposdelaempresa)hastaotrosextremadamenteserios(diseminacindevirus).

PrincipiosCdigosdetica
1. Publico: Los ingenieros de Software actuaran consistentemente con los interese del
publico.
2. Clientesyempleador:LosingenierosdeSoftwareactuarandemaneratalqueelintersde
susclientesyempleadoresseaconsistenteconelinterspblico.
3. Producto: Los ingenieros de Software se aseguraran de que sus productos y
modificacionesalcanzanlosmsaltosestndaresprofesionales.
4. Juicio:LosingenierosdeSoftwaremantendrnlaintegridadeindependenciaensujuicio
profesional.
5. Administracin: Los ingenieros de Software promovern un enfoque tico a la
administracindeldesarrolloymantenimientodelsoftware.
6. Profesin: Los ingenieros de software promovern la integridad y reputacin de la
profesinenformaconsistenteconelinterspublico.
7. Colegas:LosingenierosdeSoftwaresernjustosyapoyaranasuscolegas.
8. Unomismo:LosingenierosdeSoftwareparticiparanenunaprendizajecontinuo.

SkycharANLISISYDISEO

PARCIALII

Laprogramacinorientadaaobjetos
La programacin orientada a objetos es una de las formas ms populares de programar y viene
teniendogranaceptacineneldesarrollodeproyectosdesoftwaredesdelosltimosaos.Esta
aceptacin se debe a sus grandes capacidades y ventajas frente a las antiguas formas de
programar.

Tradicionalmente, la programacin fue hecha en una manera secuencial o lineal, es decir, una
seriedepasosconsecutivosconestructurasconsecutivasybifurcaciones.

Estos programas escritos al estilo espaguetti no ofrecen flexibilidad y el mantener una gran
cantidaddelneasdecdigoenunslobloquesevuelveunatareacomplicada.

Frente a esta dificultad aparecieron los lenguajes basados en la programacin estructurada. La


idea principal de esta forma de programacin es separar las partes complejas del programa en
mdulososegmentosqueseanejecutadosconformeserequieran.Deestamaneratenemosun
diseomodular,compuestopormdulosindependientesquepuedancomunicarseentres.

Pocoapocoesteestilodeprogramacinfuereemplazandoalestiloespaguettiimpuestoporla
programacinlineal.

Entonces,vemosquelaevolucinquesefuedandoenlaprogramacinseorientabasiempreair
descomponiendo ms el programa. Este tipo de descomposicin conduce directamente a la
programacinorientadaaobjetos.

La creciente tendencia de crear programas cada vez ms grandes y complejos llev a los
desarrolladoresacrearunanuevaformadeprogramarquelespermitacrearsistemasdeniveles
empresariales y con reglas de negocios muy complejas. Para estas necesidades ya no bastaba la
programacin estructurada ni mucho menos la programacin lineal. Es as como aparece la
programacin orientada a objetos (POO). La POO viene de la evolucin de la programacin
estructurada; bsicamente la POO simplifica la programacin con la nueva filosofa y nuevos
conceptosquetiene.LaPOOse basaenladividirelprogramaenpequeas unidadeslgicasde
cdigo. A estas pequeas unidades lgicas de cdigo se les llama objetos. Los objetos son
unidadesindependientesquesecomunicanentreellosmediantemensajes.

Entrelasventajasdeunlenguajeorientadoaobjetosseencuentran:

Fomentalareutilizacinyextensindelcdigo.
Permitecrearsistemasmscomplejos.
Relacionarelsistemaalmundoreal.
Facilitalacreacindeprogramasvisuales.
Construccindeprototipos
Agilizaeldesarrollodesoftware
Facilitaeltrabajoenequipo
Facilitaelmantenimientodelsoftware

SkycharANLISISYDISEO

LointeresantedelaPOOesqueproporcionaconceptosyherramientasconlascualessemodelay
representaelmundorealtanfielmentecomoseaposible.

Quesunobjeto?
Unobjetoesunaabstraccindeunconjuntodecosasdelmundorealdetalformaque:
Todosloselementosdelconjunto(lasinstancias)tienenlasmismascaractersticas.
Todaslasinstanciasestnsujetasayconformanlasmismasreglas.

Las caractersticas de un objeto pueden ser usadas en forma independiente. Pero juntas se
complementan.

ConceptosdelaOrientacindeObjetos:

Clase:Eslaplantillaquedescribeaunconjuntodeobjetos,conlosmismos:
Atributos(variables)
Mtodos(funciones)
Relaciones
Unobjetoesunainstanciadeunaclase.
Losobjetoscreadosapartirdeunaclase:
o Tienenunaestructuraidntica.
o Peroidentidadpropia.
UnaclaseesunTDA(TipodeDatoAbstracto.Esdefinirlascaractersticasespecialesdeunobjeto
ydesecharloirrelevante.)Esladefinicindeunnuevotipodedato.Unobjetoeslavariablede
dichotipo.Ejemplo:CLASE:ANIMALOBJETOS:Perro,Gato,Ave,etc.

Existentrestiposdeclases:
1. Clasesabstractas:
a. Representanconceptosmuygenerales.
b. Describenlainterfazcomnparaelrestodesubclases.
c. Nopuedenserinstanciadas
d. Puedenteneroperacionesabstractas.
2. Clasesconcretasocomunes:
a. Representanconceptosespecficos.
b. Puedenserinstanciadas.
c. Suelenimplementaroperacionesabstractasheredadas.
3. Clasesfinales
a. Clasesespecialesquenopuedentenerdescendencia.
b. Permiteninstanciarobjetos.

Instancia:Unainstanciaesunobjetocreadoapartirdeunaclase.Laclasedescribelaestructura
delainstancia(informacinycomportamiento),mientrasqueelestadoactualdelainstanciaes
definidoporlasoperacionesejecutadas.

Constructor: Es un mtodo muy especial, con el mismo nombre de la clase. Es llamado


automticamente cuando un objeto de una clase es creado. Inicializa las variables del objeto y
puedetomarargumentos(valores)peronopuededevolverunvalor.Unaclasepuedetenermas
SkychharANNLISISYDIISEO

deun constructor. Lapalabranewllamaaalconstructordelaclase. Sinoexiste ladefinicin de


nstructor la clase
un con c tiene un
n por defecto
o, el cual no
o hace ni reciibe nada. Si se definiera un
constru
uctorelconsttructorpordeefecto(oconstructorvaccio)sepierdee.

Abstraaccin:Visi nsimplificad dadeunareaalidad.Enfocaarseenloeseencial.POOin ntentaabstraaer


lomsimportanted deunobjeto::
Estadodelo objeto(Atribu utos)
Comportam mientodeobjeto(Mtodoss)
Comportam mientoscomu unesentreobjjetosrelacion nados.

JAVA A
publicclassAlumnno
{
privateStrringnombre;
privateStrringdomicilio
o;

publicAlumno(Stringn,Stringd)
{}

publicvoiddsetNombre(Stringn)
{}

publicStringgetNombrre()
{}
}

Alum mnoalumno1=newAlumn no(JuanPerres,LasPalm
mas);

Heren
ncia:Esunmecanismoparracompartiratributosym mtodosentreeclases.
Porlaherennciaseformaanlasjerarquasdeclases(superclasesyysubclases).
Lassubclaseesheredanloosatributosymtodosdelassuperclases.
Permitelarreutilizacind
decdigo.
SkycharANLISISYDISEO

Existendostiposdeherencia:
Simple:Dondeunaclaseheredadeotraclase.
Multiple:Dondeunaclaseheredadevariasclasesdiferentes.

Encapsulamiento:Elencapsulamientoconsisteenseparar:
Losaspectosexternosdeunobjeto.
Delosdetallesinternosdeimplementacindelmismo.
Seprotegenlosdatos(caractersticas)deunobjeto.
Seexhibesoloelcomportamientodelmismo.
Haciendonfasisenloquepuedehacer.
Nocomosepuedehacerlo.
EnJavaparaelencapsulamientoexistenmodificadoresdeacceso.Palabrasqueseponenantes
decadamiembrodelaclase.
Private:Sololosmiembrosdelaclaselospuedenver.
Public:Todoslosobjetoslospuedenver.
Protected:Sololosobjetosdelassubclaseslospuedenver.

Para acceder a los datos privados fuera de la clase, es necesario utilizar mtodos como GET y
SET.

Relacionesentreobjetos:Interaccinentredosobjetos.
Tiene:aunobjetopertenecenobjetosdeotrasclases.
Conoce:Unobjetoconocedatossobreobjetosdeotraclase.
Esun:Unobjetocompartecaractersticasconotraclase.
SkycharANLISISYDISEO

Polimorfismo:Elpolimorfismoestamuyligadoalaherencia.
Unamismaoperacin:
Puedeserejecutadaenformadiferenteporobjetosdedistintasclases.

Envidemensajes
Unobjetoestilsiestaaislado.Elmedioempleadoparaqueunobjetointeracteconotrosonlos
mensajes. Hablando en trminos un poco ms tcnicos, los mensajes son invocaciones a los
mtodosdelosobjetos.Esunaoperacinaplicadaaunobjeto,esdecirllamaraunaoperacin.

Ocultamiento:eslacapacidaddeocultarlosdetallesinternosdelcomportamientodeunaclasey
exponersololosdetallesqueseannecesariosparaelrestodelsistema.Elocultamientopermite
dos cosas: Restringir y controlar el uso de la clase. En java el ocultamiento se logra usando las
palabrasreservadas:pblicoyprotectecdelantedelasvariablesymtodos

Concurrencia:permitequediferentesobjetosactaalmismotiempousandodistintoshilosde
control.

Persistencia:eslapropiedadporlacualexistenciadeunobjetotrasciendeenelmismotiempoo
enelespacio.Permitealprogramadoralmacenar,transferiryrecuperarelestadodelosobjetos.
Un objeto persistente es aquel cuyo estado es almacenado en un medio secundario para su
posteriorreconstruccinyutilizacin,porloquesutiempodevidaesindependientedelproceso
quelocreo.
Modularidad: es la propiedad que permite subdividir una aplicacin es partes mas pequeas,
cadaunadelacualesdebesertanindependientecomoseaposibledelaaplicacinensiydelas
partesrestantes.

INTRODUCCINALUML

UML(UnifiedModelingLanguageEnEspaol,LenguajedeModeladoUnificado).

LanotacinUMLsederivayunificaenlas3metodologasdeanlisisydiseoorientadoaobjetos
masextendidas.

UMLpararepresentardiversosaspectosdelsistema:
Proporcionaralosusuariosunlenguajedemoduladovisualexpresivoyutilizableparael
desarrolloeintercambiodemodelossignificativos.
Proporcionarmecanismodeextensinyespecificacin.
Serindependientedelprocesodedesarrolloydeloslenguajesdeprogramacin.
Fomentarelcrecimientodelmercadodelasherramientasorientasaobjetos.

UMLdebeentendersecomounestndarparamodelarynocomounestndardeprocesosde
software.SeconsideranfueradelmbitodeUMLtantoloslenguajesdeprogramacinlas
herramientasyelprocesosoftware.

SkycharANLISISYDISEO

UMLesunlenguajeparaespecificar,visualizarconstruirydocumentarlosartefactosdesoftware
desdelasfacesincialesastalaimplementacindelsistema,ascomoelmodeladodeflujode
trabajoyotrossistemasnosoftware.

Extensiones:
CuandoseutilizaunlenguajedemodeladocomoUMLparacomunicar,convieneceirsealncleo
dellenguajeparaquelosmodelosnopierdanlacapacidaddepoderserentendidos.Detodas
formascuandoelmodeladorseencuentreconlanecesidadforzosadeexpresaralgofueradelos
lmitesdellenguaje,lodeberahacerdeformacontroladaparanoalterarlacapacidadde
comunicacin.Deotramanera,seriaimposibleparacualquierotrocomprenderloqueseha
hecho.

LaformamsbsicadecomunicarconceptosfueradeloslmitesdeUMLeslautilizacindenotas.
Lasnotaspermitencapturarcomentariosarbitrariosyrestriccionesqueayudanacalificarlos
modelosquesehancreado.ConunabasemasformalUMLproporcionalosestereotipos,valores
etiquetadosyrestricciones,permitiendoaadirnuevos.

Estereotipos:

Proporcionanunmecanismodeextensinparaelpropiolenguaje.Estemecanismohaceposible
definirUMLcomounconjuntomnimodesmbolosquepodranserextendidos,cuandofuere
necesarios.AlgunosestereotiposestnpredefinidosenelUMLotrospuedenserdefinidosporel
usuario.

Grficamenteunestereotiposerepresentacomounnombreentrecomillas:
<<Nombreestereotipo>>

Valoresetiquetados
EsunaextensinDelaspropiedadesdeunelementodeUML,permitiendoaadirnueva
informacinenlaespecificacindelelemento.

Grficamenteunvaloretiquetadoserepresentacomounacadenadecaracteresentrellaves
asociadaalnombredelelemento.

Lacadenaincluyeunnombre(etiquetada),unseparador(=),yunvalordeLaetiqueta.

Restricciones:
EsunaextensindelasemnticaUML,quepermiteaadirnuevasreglasomodificarlas
existentes.

DiagramasUML:
Enfuncindelasdiferentesvisitasdelmodelo,enUMLsedefinenlossiguientesdiagramas
grficos:

SkycharANLISISYDISEO

Diagramadecasosdeuso(UseCase)
Diagramadeclases(ClassDiagram)
Diagramadecomportamiento
o Diagramadeestado(StateChart)
o Diagramadeactividad(Activity)
Diagramadeinteraccin
o Diagramadesecuencia(Sequence)
o Diagramadecolaboracin(Collaboration)
Diagramadeimplementacin
o Diagramadecomponentes(Component) AUTOR
o Diagramadedespliegue(Displacement)

Estosdiagramasproporcionanmltiplesperspectivasdelsistemabajoanlisisporotrolado
podemosverelmodelodeunaformaestticaodeunaformadinmica.

MODELOSESTATICO(ESTRUTURAL)
Diagramadeobjetos
Diagramadeclases
Diagramadecomponentes
Diagramadedespliegue

MODELOUNAMICO(CONPORTAMIENTO)
Diagramadecasosdeuso
Diagramadeestado
Diagramadesecuencia
Diagramadecolaboracin
Diagramadeactividades

Los cuatro diagramas estructurales UML permiten visualizar, especificar, construir y documentar
losaspectosespecficosdeunsistema.Undiagramadedesplieguemuestraunconjuntodenodos
de componentes y sus relaciones, se relacionan con los diagramas de componentes ya que un
nodonormalmenteincluyeunoomscomponentes.

Un diagrama de componentes muestra un conjunto de componentes y sus relaciones. Los


diagramas de componentes se relacionan con los diagramas de clase ya que un componente
normalmentesecorrespondeconunaomsclasesointerfaces.

Undiagramadeclasesrepresentaunconjuntodeclases,interfacesylasrelacionesentreellas.
Undiagramadeobjetosrelacionaunconjuntodeobjetosysusrelaciones.

Los 5 diagramas de componentes de UML se emplean para visualizar, especificar, construir y


documentarlosaspectosdinmicosdeunsistema.

Undiagramadeactividades:esuntipoespecialdediagramadeestadosquemuestraelflujo
secuencialoramificadodeactividadesdeunsistema.

SkycharANLISISYDISEO

Diagramas de interaccin: se da este nombre colectivo a los diagramas de secuencia y a los


diagramas de colaboracin. Ambos diagramas son isomorfos es decir se pueden convertir uno u
otrosinperdidadeinformacin.

Undiagramadesecuenciaesundiagramadeinteraccinqueresultalaordenacintemporal
de los mensajes. Presenta un conjunto de objetos que envan y residen mensajes enviados y
recibidosporellos.

Diagrama de colaboracin: es un diagrama de interaccin que resulta la organizacin


estructuraldelosobjetosqueenvanyrecibenmensajes.

Diagramas de caso de uso: organizan los comportamientos del sistema. Un caso de uso
describeposiblementeenlenguajenaturalunaformaenqueunactordelmundoreal(persona,
organizacin o sistema) interaccionan con el modelo. El modelo de caso de uso documenta el
comportamiento de sistema desde el punto de vista del usuario, permitiendo representar las
funcionesquesedeseanenelsistemaylasrelacionesentreellas.Aunquelapartemsvisiblede
dicho modelo son los diagramas de casos de uso, suele ir acompaado de una especificacin
textualdecadaunodeloscasosdeuso.

Actores:noformanpartedelsistema,sinoquerepresentanelementosqueinteractanconel.Un
actorpuedeintroducir,recibirointroducirinformacindesdeohaciaelsistema.
Casos de uso: modelan un dialogo entre el actor y el sistema describiendo la funcionalidad que
ofreceelsistemaalactor,elconjuntodecasosdeusodesistemaconstituyentosaslasformasde
usolasrelacionespuedeserdedostipos:

incluye(include)
extiende(extend)

Los principales objetivos de los modelos de caso de uso son: permitir la comunicacin entre los
desarrolladoresylosclientesousuariosdurantelacapturaderequisitos,planificarelprocesode
softwareyserlabaseparalavalidacindelsistema.
Todosistematienecomounmnimounsistemadecasodeusoprincipal(mainusecase),quees
unarepresentacingraficadelentornodelsistema(actores)ysufuncionalidadprincipal(casode
uso).

Undiagramadecasodeusomuestraporlotantolosdistintosrequisitosqueseesperandeuna
aplicacinosistemaycomoserelacionaconsuentorno.

Uncasodeusoquedenotaunrequisitofuncionalexigidoalsistema,serepresentanenelsistema
porunaelipseyunnombresignificativo.

Unactoresunaentidadqueutilizaalgunodeloscasosdeusodelsistemaserepresentamediante
unsmboloacompaadodeunnombresignificativo.

Un actor en un caso de uso representa un rol que alguien o algo podra desempear. Entre los
elementos de un diagrama de casos de uso se pueden presentar tres tipos de relaciones,
representadosporlneasdirigidasonoentreellos:
SkycharANLISISYDISEO

Comunicacin(Communicates).relacionanentreunactoryuncasodeusoquedenotala
participacin del actor en dicho caso de uso todas las lneas que salen del actor denota
estetipodeasociacin(enrealidadestereotipadacomoCommunicates).
Incluye (Include).en UML antiguo use. Relacin de dependencia entre dos casos de uso
quedenotainclusindelcomportamientodeunescenarioenotro.
Extendido(Extends).relacindedependenciaentredoscasosdeusoquedenotaqueun
casodeusoesunaespecificacindeotro.

Seutilizaunarelacindetipo<<extends>>entrecasosdeusocuandonosencontramosconcasos
deusosimilaraotroperoquehacealgomsqueeste(variante).Porelcontrarioutilizaremosuna
relacindetipo<<include>>cuandonosencontremosconunapartedecomportamientossimilar
endoscasosdeusoynoqueremosrepetirladescripcindedichocomportamientocomn.
Enunarelacin<<extends>>,unactorquelleveacaboelcasodeusobasepuederealizaronosus
extensiones. Mientras en una relacin <<include>> el actor que realiza el caso de uso base
tambinrealizaelcasodeusoincluido.

En general utilizaremos <<extends>> cuando se presenta una variacin del comportamiento


normalyengeneralutilizaremos<<include>>cuandoserepiteuncomportamientoendoscasos
de uso y queremos evitar dicha repeticin. Adems en un diagrama de caso de uso (include y
extends),puedeexistirrelacionesdeherenciayaseaentrecasosdeusooentreactores.

Los modelos de casos de uso son importantes puntos de partida para el desarrollo de los
diagramasdeclase.

FormatodeCasodeuso

FORMATODECASOSDEUSO
PROYECTO PSP0 DESCRIPCION FECHA CREACION
OBJETIVO:CASODEUSODEPLANEACION
CASODEUSO P0CU001 PROGRAMADOR

ANALISTA ACT ALEJANDOCUAEVASTOLEDO

PRECONDIACIONES Sistemaenlnea

ACTOR(ES)

PROGRAMADOR:esaquelqueescribe,depuraymantieneelcdigofuente
deunprogramainformtico
LIDER:personaconlacapacidaddetomarlainiciativa,gestionar,
convocar,promover,incentivar,motivaryevaluaraungrupooequipo.

ACTOR SISTEMA

1.INGRESADATOS 1.DESPLIEGAFORMULARIOS
2.ASIGNAPROGRAMAS 2.SALIR
3.ALTAPROYECTO
4.IMPRIMERESUMEN

EXEPCIONES?NINGUNA