Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Encontrar las definiciones de los siguiente conceptos:
REFERENCIAS
martes, 22 de noviembre de 2011
[PUNTOS EXTRA] Diagrama de Clases con "Umbrello"
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Ejercicio realizado en el salón de clases.
Saludos!
[PUNTOS EXTRA] Diagramas UML
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
UML (Unified
Modeling Language)
Es un lenguaje gráfico para visualizar, especificar, construir y
documentar un sistema. UML ofrece un estándar para describir un
"plano" del sistema (modelo), incluyendo aspectos conceptuales tales
como procesos de negocio, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y componentes
reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Diagramas UML
-
La descripción escrita del comportamiento del
sistema al afrontar una tarea de negocio o un requisito de
negocio. Esta descripción se enfoca en el valor suministrado por el sistema a
entidades externas tales como usuarios humanos u otros sistemas.
-
La posición o contexto del caso de uso entre otros
casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de
usos coherentes y consistentes promueven una imagen fácil de comprender del
comportamiento del sistema, un entendimiento común entre el
cliente/propietario/usuario y el equipo de desarrollo.
Es práctica común crear especificaciones suplementarias para capturar
detalles de requisitos que caen fuera del ámbito de las descripciones de los
casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como:
rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
El diagrama describe la funcionalidad de un Sistema
Restaurante muy simple. Los casos de uso están representados por elipses y
los actores están, por ejemplo, los casos de uso se muestran como parte
del sistema que está siendo modelado, los actores no.
La interacción entre actores no se ve en el diagrama de casos de
uso. Si esta interacción es esencial para una descripción coherente del
comportamiento deseado, quizás los límites del sistema o del caso de uso deban
de ser re-examinados. Alternativamente, la interacción entre actores puede ser
parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son
una especie de rol, un usuario humano u otra entidad externa pueden jugar
varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma
persona.
REFERENCIAS
[PUNTOS EXTRA] Casos de Uso
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
A continuación, les presento unos ejemplos de Diagramas de Casos de Uso realizados en el salón de clases en equipo.
El equipo consistió en:
- Lizbeth A. Treviño Treviño
- Jorge N. Montano González
> Buscaminas
> iTunes
> SIASE
Saludos!
[PUNTOS EXTRA] Patrones de Diseño
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
Los patrones de diseño son la base para la búsqueda de
soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño
de interacción o interfaces.
Un patrón de
diseño es una solución a un problema de diseño. Para que una solución sea
considerada un patrón debe poseer ciertas características. Una de ellas es que
debe haber comprobado su efectividad resolviendo problemas similares en
ocasiones anteriores. Otra es que debe ser reutilizable,
lo que significa que es aplicable a diferentes problemas de diseño en distintas
circunstancias.
Un patrón de
diseño es:
-
una
solución estándar para un problema común de programación
-
una
técnica para flexibilizar el código haciéndolo satisfacer ciertos criterios
-
un
proyecto o estructura de implementación que logra una finalidad determinada
-
un
lenguaje de programación de alto nivel
-
una
manera más práctica de describir ciertos aspectos de la organización de un programa
-
conexiones
entre componentes de programas
-
la
forma de un diagrama de objeto o de un modelo de objeto.
Los patrones
de diseño pretenden:
-
Proporcionar
catálogos de elementos reusables en el diseño de sistemas software.
-
Evitar
la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
-
Formalizar
un vocabulario común entre diseñadores.
-
Estandarizar
el modo en que se realiza el diseño.
-
Facilitar
el aprendizaje de las nuevas generaciones de diseñadores condensando
conocimiento ya existente.
Asimismo, no
pretenden:
-
Imponer
ciertas alternativas de diseño frente a otras.
-
Eliminar
la creatividad inherente al proceso de diseño.
No es
obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el
mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta
que en un caso particular puede no ser aplicable. "Abusar o forzar el uso
de los patrones puede ser un error".
Según la
escala o nivel de abstracción:
-
Patrones de arquitectura: Aquellos que
expresan un esquema organizativo estructural fundamental para sistemas de
software.
-
Patrones
de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o
sus relaciones) con las que construir sistemas de software.
-
Dialectos:
Patrones de bajo nivel específicos para un lenguaje de programación o entorno
concreto.
-
Interacción:
Son patrones que nos permiten el diseño de interfaces web.
Además,
también es importante reseñar el concepto de "anti-patrón de diseño", que con forma
semejante a la de un patrón, intenta prevenir contra errores comunes de diseño
en el software. La idea de los anti-patrones es dar a conocer los problemas que
acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes
sistemas acaben una y otra vez en el mismo callejón sin salida por haber
cometido los mismos errores.
REFERENCIAS
[PUNTOS EXTRA] Metodologías de Análisis y Diseño de Software
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
El Análisis
El análisis
consiste de un proceso que por medio una exploración básica procura determinar
los elementos a ser tenidos en cuenta para construir las bases de una solución.
Para esto hay
varias estrategias y documentos, los más llamativos son la lluvia de ideas y
los anteproyectos.
En la lluvia
de ideas generalmente se peca por considerar las cosas más fáciles de lo que
realmente son y por dejar ocultos algunos de los aspectos que son de
importancia crítica en el proyecto.
En cuanto al
anteproyecto se puede determinar que en la medida que sus tópicos sean llenados
a conciencia pueden ayudar a garantizar que el análisis sea realmente fructífero.
En esta etapa
también pueden ser levantados otros documentos que pueden incluso tratar de
adelantarse a la etapa de diseño, tales como la identificación de casos de uso
y la identificación de interrelaciones entre los subsistemas identificados o
las relaciones de comunicación con sistemas externos.
De este
aspecto solo una recomendación: la prisa no es buena, el afán por
detallar lo desconocido conduce a una ignorancia que sustenta la confianza
infundada que al final solo lleva a tener que volver al principio a hacer las
cosas bien y con buena letra.
El objeto del
análisis en si es muy simple y es tener una luz sobre donde comenzar. Tan
pronto se identifica esa luz, una lista de cosas por llevar a cabo (sin ser tan
profundos) se puede contemplar algo más.
Pero de lo
anterior que se debe hacer hasta qué punto se debe llegar, la respuesta es
simple también llegue hasta cuando note que empieza a diseñar, es decir, cuando
empiece a ver cantidades y la necesidad de abordar detalles complejos deténgase
a respirar. Si las cosas llegan a tomar un nivel de complejidad que lo lleva a
un consumo muy largo en análisis deténgase también ya habrá ocasión de pensar
en cómo solucionarlo lo cual necesariamente será en el diseño, lo importante en
esta etapa es identificarlo y en la medida de lo deducible rápidamente y concisamente
todo aquello que se le relacione.
Para lo
anterior que se debe identificar, y opcionalmente definir, en el análisis:
Identifique
la justificación para realizar el proyecto en la medida que esta sustente bien
el proyecto este se podrá proyectar como una inversión estable y rentable.
Listado de
instancias principales y tareas. Liste los conceptos más relevantes que
encuentre a su paso (personas, entidades, cuentas, reportes, estadísticas,
seguridad, clientes, usuarios, costos, personal, recursos, tiempo) y sus tareas
básicas respondiendo para ambos con textos descriptivos básicos inspirados en
aquello que el cliente expreso. Con lo anterior elabore un cronograma dadas las
prioridades.
Alcances y limitaciones,
básicas pero sustentables. Si encuentra algo que pueda tomar muchos recursos márquelo
y asígnele una prioridad o una cantidad.
Identificar a
los participantes del proyecto y los roles que jugaran en el mismo.
Un nombre
para el proyecto, uno en lo posible atractivo
Defina lo más
claro posible un objetivo principal y varios específicos a nivel de metas.
El Diseño
Consiste del
proceso que toma los insumos identificados en el análisis para
decantarlos para dar lugar a conceptos, ideas, procesos, operaciones,
etc., que son en si el primer acercamiento, no precisamente a la solución, pero
si a identificar claramente la problemática o los requerimientos a soportar.
De lo
anterior, la premisa es conocer bien que se debe como construirlo y la única
preocupación en la mente de cada miembro del equipo de trabajo es como dar vía
con las herramientas existentes a una solución lo más cercana a lo deseado con
toda la calidad del caso.
Visto de otra
forma es en si la necesidad de saber cómo usar bien lo que hay a la mano, aun
si no se es un experto del todo, para llegar a conseguir la meta siendo conscientes
que se hace lo mejor en cada paso y que el factor de riesgo de tener que
corregir es mínimo y el factor de mejora está supeditado no a la necesidad de
completar cosas que no se hacen sino en la inevitable necesidad que producen
las cosas que cumplen lo que deben hacer y es evolucionar para dar más
soluciones.
[PUNTOS EXTRA] Casos de Sistemas Fallidos
Dra. Sara Elena Garza Villarreal
Materia: Programación Orientada
a Objetos
Matricula: 1454810
Hora: M1-M3 (Jueves)
El “Happy Day” se
conoce cuando el programador construye e implementa el sistema y al momento de
hacer las pruebas y distribuir el producto no llega a presentar ningún error,
esas ocasiones son contadas.
Siempre habrá situaciones en las
que después de analizar, desarrollar e implementar el sistema, habrá algún
detalle que corregir en dicho sistema, ningún sistema es perfecto y es por lo
mismo que existen los ingenieros para corregir los problemas que surgen en los
sistemas.
La
crisis del Software
Se implementó en el tiempo que se
creó el software, ya que no siempre se obtenían los resultados esperados, los
costos eran excesivos y poco flexibles, por ese motivo surgió la ingeniería de
software en 1968.
La crisis de software
se refiere a que no es fácil ni existen herramientas para
escribir programas libres de errores, fáciles de entender ni tampoco que sean
verificables. Tampoco existen herramientas para medir exactamente cuánto tiempo
tomará desarrollar un programa. Así que tampoco se puede definir exactamente
cuánto tiempo tomará la creación del proyecto ni la cantidad de personal
necesario.
Las aplicaciones son muy
complejas para utilizarse por una sola persona, por lo que hoy en día sigue
siendo muy difícil definir estimaciones precisas de los costos y del
tiempo necesario para un proyecto.
Al final de la entrada se
encuentra una liga a un video donde se presenta el comercial de
Windows 98.
Y también el siguiente caso es un
caso singular de Bill Gates y su nuevo Win 98, y en ésta ocasión fue
un evento cubierto por la CNN. En este caso el compañero de Bill
Gates estaba explicando la capacidad de Win 98 para instalar un scanner
con sus propios driver pero ocurrió un error fatal y se
muestra la pantalla azul de la muerte por lo que se sorprende el compañero
de Bill Gates. Al final Bill Gates aclara: “Debe ser por esto por lo que aún no
estamos comercializando Windows 98, ¿¿no??“, a lo que su compañero apenado
responde, “Absolutamente, absolutamente!!“.
Al final de la entrada se
encuentra una liga a un video donde se presenta lo mencionado recientemente.
REFERENCIAS
Suscribirse a:
Entradas (Atom)