Aplicaciones en Ambientes Propietarios 1 7

APLICACIONES EN AMBIENTES
PROPIETARIOS
ESCUELA POLITÉCNICA NACIONAL
FACULTAD DE SISTEMAS
INGENIERÍA EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN
M.Sc. Ing. Marcos Raúl Córdova Bayas

2015
11/07/2021 1
1. Principios de diseño de software
1.1 Niveles de abstracción: diseño arquitectónico
- El diseño arquitectónico permite entender cómo debe organizarse

un sistema y cómo tiene que diseñarse la estructura global del
mismo.
- Es la primera etapa en el proceso de diseño de software.
- Es el enlace entre el diseño y la ingeniería de requerimientos.
- Identifica los principales componentes estructurales en un sistema
y la relación entre ellos.
- Salida: un modelo arquitectónico que describe la organización del
sistema como un conjunto de componentes de comunicación.
11/07/2021 2
- En procesos ágiles, una de las primeras etapas en el

proceso de desarrollo es establecer una arquitectura
global del sistema.
- En este caso no existe el desarrollo incremental de
arquitecturas.
- La refactorización de componentes en respuesta a los
cambios es más fácil que refactorizar una arquitectura.
11/07/2021 3
- Una especificación de un sistema no debe incluir cierta

información de diseño, excepto para sistemas muy
pequeños.
- La descomposición arquitectónica es por lo general
necesaria para estructurar y organizar la especificación.
- En este caso, se puede proponer una arquitectura abstracta
donde se asocien grupos de funciones del sistema o
características con componentes o subsistemas a gran
escala.
11/07/2021 4
- Las arquitecturas de software se diseñan en dos niveles de

abstracción:
- Arquitectura en pequeño:
- Se interesa por la arquitectura de programas individuales.
- Se preocupa de la forma en que el programa individual se separa en componentes
- Arquitectura en grande:
- Se interesa por la arquitectura de sistemas empresariales complejos que incluyen
otros sistemas, programas y componentes de programa.
- Estos sistemas se distribuyen a través de diferentes computadoras, que diferentes
compañías administran y poseen.
- Forman parte de las arquitecturas de los sistemas distribuidos.
11/07/2021 5
- Ventajas de diseñar y documentar la arquitectura de

software:
1. Comunicación con los participantes: permite discusiones de un
amplio número de participantes.
2. Análisis del sistema: permite determinar si la arquitectura cubre
requerimientos como rendimiento, fiabilidad y mantenibilidad.
3. Reutilización a gran escala: la arquitectura es la misma para
sistemas con requerimientos similares, por lo que puede soportar
reutilización de software a gran escala. Ej: arquitecturas de línea
de productos.
11/07/2021 6
- La arquitectura de software sirve:

- Como un plan de diseño para la negociación de
requerimientos del sistema.
- Como un medio para establecer discusiones con clientes,
desarrolladores y administradores.
- Como herramienta poderosa para la administración de la
complejidad: oculta detalles y permite a los diseñadores
enfocarse en las abstracciones clave del sistema.
11/07/2021 7
- Se modelan usando diagramas de bloques simples.

- Cada recuadro en el diagrama representa un componente.
- Recuadros dentro de recuadros indican que el
componente se dividió en subcomponentes.
- Flechas significan que los datos y/o señales de control
pasan de un componente a otro en la dirección de las
flechas.
11/07/2021 8
ARQUITECTURA DE UN SISTEMA PARA UN ROBOT EMPACADOR
Sistema de visión
Sistema de
Controlador Controlador
identificación de
de brazo de sujetador
objetos
Sistema de
selección de
empaque
Sistema de Controlador de
empacado transportadora
11/07/2021 9
- Formas de utilización de un modelo arquitectónico:

1. Como una forma de facilitar la discusión acerca del diseño del
sistema:
 El modelo identifica componentes clave que se desarrollarán, lo que
permite asignar personas para planear el desarrollo.
2. Como una forma de documentar una arquitectura que se haya
diseñado:
 Se produce un modelo de sistema completo que muestre los
diferentes componentes en un sistema, sus interfaces y conexiones.
Esto facilita la comprensión y la evolución del sistema.
11/07/2021 10
1.2 Niveles de abstracción: diseño detallado
- Tiene que ver con describir de manera completa los componentes de un

sistema software.
- Se detallan los componentes del diseño con el fin de que puedan ser
implementados de manera automática.
- Se puede utilizar seudocódigo, de tal manera que el paso a la programación
sea más fácil.
- Es el paso final del diseño, a partir del cual se puede ingresar a la etapa de
implementación de software.
- También se pueden usar diagramas, tales como el diagrama de clases de
diseño, el diagrama de secuencia o colaboración de diseño y los diagramas
de estado, todos estos usando UML y desarrollo orientado a objetos.
11/07/2021 11
1.3 Separación de aspectos
• Permite separar las competencias de un sistema en elementos independientes,

evitando incluir diferentes competencias en la misma abstracción lógica.
• Las competencias transversales se pueden representar como aspectos, lo que
permite comprenderlas, reutilizarlas y modificarlas de manera independiente,
sin tomar en cuenta dónde se use el código.
• Ejemplo: la autenticación de usuario puede ser un aspecto y se la implementa
de tal forma que solicite un usuario y una contraseña.
• Esto puede integrarse automáticamente en el programa siempre que se
requiera autenticación.
• Da origen a la programación orientada a aspectos (POA) y Lenguajes
orientados a aspectos (LOA) como AspectJ.
11/07/2021 12
1.4 Ocultamiento de información
• Se define como el uso de un lenguaje de programación para ocultar la representación

de las estructuras de datos y controlar el acceso externo a dichas estructuras.
• Se conoce también como data hidding.
• Se aplica en orientación a objetos con el concepto de encapsulamiento.
• Los datos se definen como un estructura de datos, y sobre esa estructura se definen
las operaciones que pueden acceder a los datos.
• Se conocen también como datos abstractos.
• La única manera de acceder a los datos es mediante las funciones definidas sobre
ellos.
• De esta manera se pueden desarrollar diferentes aplicaciones que usen los mismos
datos abstractos, pero las aplicaciones solamente pueden acceder a los datos
mediante las funciones u operaciones ya definidas sobre ellos.
11/07/2021 13
1.5 Cohesión y acoplamiento
• La cohesión implica que un módulo de un

sistema debe realizar solo una tarea a la vez y
no varias.
• El acoplamiento implica que debe haber
independencia entre módulos.
• Se busca alta cohesión y bajo acoplamiento.
11/07/2021 14
1.6 Reutilización de estructuras estándares
• Algunas de las más usadas actualmente se denominan
frameworks.
• Framework es una estructura genérica que se extiende
para crear una aplicación o un subsistema más específico.
• Según Schmidt (2004) framework es un conjunto
integrado de artefactos de software (tales como clases,
objetos y componentes) que colaboran en la facilitación
de una arquitectura de reutilización para una familia de
aplicaciones relacionadas.
11/07/2021 15
• Brindan soporte para características genéricas que
puedan ser utilizadas en todas las aplicaciones de un
tipo similar.
• Ejemplo: un framework de interfaz de usuario da
soporte para manejo de evento de interfaz e incluirá
un conjunto de artilugios que pueden usarse para
construir despliegues.
• El desarrollador especializa éstos agregando
funcionalidad específica para una aplicación particular.
11/07/2021 16
• Los frameworks ofrecen una arquitectura que sirve de
esqueleto para la aplicación.
• Permite reutilizar clases específicas.
• La arquitectura se define por las clases de objetos y sus
interacciones.
• Las clases se reutilizan directamente y pueden
extenderse utilizando la herencia, por ejemplo
• Los frameworks son específicos del lenguaje: Java, C#,
C++, Ruby, Phyton.
11/07/2021 17
• Fayad y Schmidt (1997) definen 3 clases de frameworks:
1. Frameworks de infraestructura de sistema.
- Apoyan el desarrollo de infraestructuras de sistema, como comunicaciones, interfaces de usuario y
compiladores.
2. Frameworks de integración de middleware.
• Conjunto de estándares y clases de objetos asociados que soportan comunicación de componentes
e intercambio de información. Ejemplos: .NET de Microsoft y EJB (Enterprise Java Beans).
3. Frameworks de aplicación empresarial.
• Se ocupan de dominios de aplicación específicos: Sistemas de telecomunicaciones o financieros.
• El conocimiento del dominio de la aplicación integra y apoya el desarrollo de aplicaciones de usuario
final.
4. Frameworks de aplicación Web (WAF).
• Son más recientes y apoyan la construcción de sitios Web dinámicos.
• La arquitectura de un WAF se basa por lo general en el patrón compuesto Modelo-Vista-Controlador
(MVC).
11/07/2021 18
2. Paradigmas de diseño
2.1 Diseño estructurado
- Es orientado a procesos
- Se basa en la descomposición top-down (de arriba hacia abajo) de los
sistemas
- Propone 3 diagramas:
- DFD (Diagrama de Flujo de Datos): modela los procesos como círculos o elipses,
los flujos con líneas con flechas y los depósitos como 2 líneas paralelas.
- DER (Diagrama Entidad Relación): modela los datos como rectángulos, los
atributos como elipses conectadas a los datos y las relaciones entre datos como
rombos.
- DTE (Diagramas de Transición de Estados): usados básicamente para sistemas de
tiempo real. Permite modelar los estados como rectángulos y las transiciones
como líneas con flechas.
11/07/2021 19
2.2 Análisis y diseño orientado a objetos
- Es orientado a datos
- Se basa en la identificación de objetos del mundo real para
representarlos en software.
- Actualmente se usa un proceso muy conocido como UP (Unified
Process o Proceso Unificado) y UML (Unified Modeling Language –
Lenguaje de Modelamiento Unificado) como metodología de
desarrollo.
- Siguiendo el proceso y UML, se empieza con la identificación de
casos de uso y se sigue el proceso apoyado de varios diagramas
propuestos por UML, como clases, objetos, actividades, estado,
secuencia, colaboración, componentes y despliegue.
11/07/2021 20
2.3 Diseño orientado a eventos
• Muestra cómo un sistema responde a eventos externos e
internos.
• Base: un sistema tiene un número finito de estados.
• Los eventos (estímulos) pueden causar una transición de
un estado a otro.
• Es útil particularmente para sistemas de tiempo real.
• Estos métodos de diseño en tiempo real fueron
propuestos por Ward y Mellor (1985) y Harel (1987, 1988)
• Se usan los diagramas de estado en UML.
11/07/2021 21
2.4 Diseño a nivel de componentes
• Se basa en la reutilización de componentes de software.
• Se motiva porque el desarrollo OO no conducía a un
reutilización extensa.
• Los componentes son abstracciones de alto nivel y se
definen mediante sus interfaces.
• Son más grandes que los objetos individuales.
• Todos los detalles de implementación se ocultan a otros
componentes.
11/07/2021 22
• Se sigue un proceso de definir, implementar e integrar o
componer los componentes independientes e
imprecisos en los sistemas.
• Ayuda a enfrentar la complejidad y a entregar un
software con mayor rapidez.
• Fundamentos:
1. Componentes independientes que se especifican por
completo mediante sus interfaces.
• Debe existir separación clara entre la interfaz y su implementación.
11/07/2021 23
• Fundamentos:
2. Estándares de componentes que facilitan la integración de éstos.
– Definen, a un nivel mínimo, cómo deben especificarse las
interfaces y cómo se comunican los componentes.
– Algunos modelos definen las interfaces que deben
implementarse por todos los componentes integrantes.
– Al usar estándares, su ejecución es independiente del lenguaje
de programación utilizado.
– Componentes escritos en diferentes lenguajes pueden integrarse
en el mismo sistema.
11/07/2021 24
• Fundamentos:
3. Middleware que brinda soporte de software para integración de
componentes.
– Permiten que componentes independientes distribuidos trabajen
en conjunto, porque el middleware soporta las comunicaciones
de componentes.
– El middleware maneja eficientemente los conflictos de bajo nivel
y permite enfocarse en problemas relacionados con la aplicación.
– Asigna recursos, gestiona transacciones, seguridad y
concurrencia.
11/07/2021 25
• Fundamentos:
4. Un proceso de desarrollo que se engrana con la
ingeniería de software basada en componentes.
• Principios de diseño orientado a componentes:
1. Los componentes son independientes:
• Sus ejecuciones no interfieren entre sí.
• Se ocultan los detalles de la implementación.
• Se puede cambiar la implementación sin afectar al resto
del sistema.
11/07/2021 26
• Principios de diseño orientado a
componentes:
2. Los componentes se comunican a través de
interfaces bien definidas:
– Si las interfaces se mantienen, es posible sustituir
un componente por otro.
– Se ofrece entonces funcionalidad adicional o
mayor.
11/07/2021 27
• Principios de diseño orientado a
componentes:
3. Las infraestructuras de componentes ofrecen
varios servicios estándar que pueden usarse en
sistemas de aplicación.
– Esto reduce la cantidad de código nuevo que debe
desarrollarse.
11/07/2021 28
2.5 Diseño centrado en la estructura de datos
• Permite diseñar el sistema basado en una perspectiva
estructural.
• Se modela la organización de un sistema o la estructura
de datos que procese el sistema.
• Los datos son la abstracción más importante.
• Son la base para desarrollar sistemas de información o
empresariales.
• Se basan en los modelos ER o en los diagramas de clases
y objetos en desarrollo OO.
11/07/2021 29
2.6 Diseño orientado a aspectos
• Identifica los aspectos del sistema.
• Los aspectos implementan los requerimientos no
funcionales del sistema.
• Los aspectos son transversales al software.
• Usan lenguajes orientados a aspectos y lenguajes
funcionales.
• Los lenguajes funcionales pueden ser desde
ensamblador, pasando por lenguajes estructurados,
hasta orientados a objetos.
11/07/2021 30
2.7 Diseño orientado a la función
• Se determina como abstracción fundamental la funcionalidad que se
incluirá en el sistema.
• También implica determinar cuál es la funcionalidad que ofrece el
entorno del sistema.
• Unos procesos podrán implementarse, mientras que otros podrán ser
manuales o soportados por sistemas diferentes.
• Se determinan posibles traslapes en la funcionalidad con los sistemas
existentes.
• También se determina dónde tiene que implementarse nueva
funcionalidad.
• Se determina siempre cuál es la frontera entre el sistema y su entorno.
11/07/2021 31
2.8 Diseño orientado a los servicios
• Los servicios son un desarrollo natural de los
componentes de software, donde el modelo de
componentes es, en esencia, un conjunto de estándares
asociados con servicios web.
• Servicio:
– Un componente de software de reutilización, debidamente
ajustado, que ofrece discreta funcionalidad, la cual puede
distribuirse y a la que se accede de manera programática. Un
servicio Web es un servicio al que se accede mediante
protocolos estándar de Internet y basados en XML.
11/07/2021 32
• Los servicios deben ser independientes y ajustarse debidamente.
• Los servicios siempre deben operar en la misma forma, sin importar su
entorno de ejecución.
• Sus interfaces son una interfaz «proporciona» que permite el acceso a la
funcionalidad del servicio.
• Los servicios tienen la intención de ser independientes y utilizables en
diferentes contextos.
• Por tanto, no tienen una interfaz «requiere» que, en diseño orientado a
componentes, define a los otros componentes del sistema que deben estar
presentes.
• Los servicios se comunican mediante el intercambio de mensajes, expresados
en XML, y dichos mensajes se distribuyen con protocolos estándar de
transporte de Internet como HTTP y TCP/IP.
11/07/2021 33
• Se basa en la ingeniería del servicio, que es el proceso de
desarrollo de servicios para reutilización en aplicaciones
orientadas a servicios.
• El servicio debe representar una abstracción de reutilización
que podría ser útil en diferentes sistemas.
• Se debe diseñar funcionalidad generalmente útil asociada con
dicha abstracción.
• Se debe garantizar que el servicio es robusto y fiable.
• Deben documentar el servicio de modo que puedan descubrir
y comprender los usuarios potenciales.
11/07/2021 34
• Etapas lógicas en el proceso de ingeniería del servicio:
1. Identificación de candidatos a servicio, donde se identifican
los posibles servicios que se podrían implementar y se
definen los requerimientos del servicio.
2. Diseño del servicio, donde se diseñan las interfaces lógica y
de servicio WSDL.
3. Implementación y despliegue del servicio, donde el servicio
se implementa, se prueba y se pone a disposición del
usuario.
11/07/2021 35
• El punto de partida es un servicio existente o un
componente que ser convertirá a servicio.
• El proceso de diseño implica generalizar el
componente existente de manera que se eliminen
características específicas de la aplicación.
• Implementar significa adaptar el componente al
agregar interfaces de servicio e implementar las
generalizaciones requeridas.
11/07/2021 36
3. Modelos estructurales
• Muestran la organización de un sistema, en términos de
los componentes que constituyen dicho sistema y sus
relaciones.
• Pueden ser:
– Modelos estáticos: muestran la estructura del diseño del
sistema.
– Modelos dinámicos: revelan la organización del sistema cuando
se ejecuta.
– Se crean cuando se discute y diseña la arquitectura del sistema.
– En UML se usan los diagramas de componentes, de paquete y
de implementación para realizar los modelos arquitectónicos.
11/07/2021 37
3.1 Diagramas de clase
• Se usan para desarrollar un modelo de sistema
orientado a objetos.
• Muestran las clases en un sistema y sus
relaciones.
• Las clases se consideran como la definición
general de un tipo de objeto del sistema.
• La relación es un vínculo entre clases.
11/07/2021 38
• Los objetos representan algo en el mundo real:
paciente, receta, médico, etc.
• En la implementación se definen objetos de
implementación adicionales que se usan para dar
la funcionalidad requerida del sistema
• El enfoque a usarse será el de modelar objetos del
mundo real, como parte de los requerimientos o
como procesos de diseño del software.
11/07/2021 39
• El proceso empieza identificando objetos del mundo real que
sean relevantes para la solución del problema.
• Se los representa como clases dentro de un rectángulo
dividido en tres partes:
– Nombre de la clase, que debe empezar en mayúscula.
– Atributos, que incluyen el nombre con minúscula, su tipo y
opcionalmente su valor inicial.
– Operaciones: que contiene el nombre, paréntesis y opcionalmente
dentro de los paréntesis los argumentos con tipo, y luego del
paréntesis derecho el tipo de valor devuelto, si la operación
devuelve algún valor.
11/07/2021 40
Paciente
11/07/2021 41
• Herencia: permite definir una sola vez atributos y operaciones
comunes a varias clases, denominadas subclases, y heredar sin
volverlas a definir, a partir de una clase denominada superclase.
• Se usa el símbolo de una línea con flecha ancha que apunta a la
superclase.
• Las subclases quedan del otro lado de la línea.
• Las subclases deben agregar por lo menos un atributo y/o una
operación propia, adicional a lo que heredan y, que deben ser
diferentes a las de las demás subclases.
• El nombre de la relación es: «es un tipo de»
• Ejemplo: Desktop «es un tipo de» Computador.
11/07/2021 42
Cuenta
número : String
saldo : float
Depositar(c:String, ve:float, vch:float)
CuentaCorriente CuentaAhorros
sobregiro : float interés : float
11/07/2021 43
• Agregación: muestra una relación en donde hay
objetos que representan el todo y otros que
representan las partes.
• El nombre de la relación es: «es parte de». Ejemplo:
Monitor «es parte de» Desktop.
• Si el todo depende de las partes, se llama
«agregación».
• Si las partes dependen de la existencia del todo se
denomina «composición».
• El símbolo es el «brillo» o «diamante».
11/07/2021 44
Desktop
marca : String
modelo : String
Desktop()
Monitor Teclado
resolución : String númeroTeclas : int
11/07/2021 45
3.2 Diagramas de objetos
• Es similar al diagrama de clases, pero con los
nombres de los objetos involucrados.
• Los atributos ya no se muestran como tales
sino se colocan los valores de los mismos.
• No deben aparecer operaciones, pero se estila
mostrarlas por motivos de entendimiento.
• Permiten validar los diagramas de clases.
11/07/2021 46
aap : Materia
Aplicaciones en Ambientes Propietarios
SIC554
victoria : Estudiante 4
Karla obligatoria
Victoria toma Ingeniería de Software
Yánez
Escarabay
Av. El Inca y Nogales
2430337
s toma inteligencia artificial : Materia
22-06-1994 Inteligencia Artificial
f SIC524
fe 4
0984061747 obligatoria
Inteligencia - Artificial
11/07/2021 47
3.3 Diagramas de componentes
• Son diagramas que se muestran en la etapa de
implementación.
• Permiten agrupar clases y objetos en
componentes que puedan ser implementados
en el sistema.
• Se usan los estándares de UML, que se
muestran a continuación.
11/07/2021 48
Diagrama de componentes a nivel de
subsistemas
Subsistema de Subsistema de
Matrículas Inscripciones
Subsistema de
Notas
11/07/2021 49
Diagrama de componentes a nivel de
componentes dentro de subsistemas
Ejemplo: Subsistema de Matrículas
Estudiante.cs Materia.cs
11/07/2021 50
4. Modelos de comportamiento
• Son diagramas que muestran la parte
dinámica del sistema.
• Muestran la interacción del sistema con el
medio externo.
• Muestran la secuencia de actividades que
realiza un caso de uso.
• Muestran los objetos involucrados en un caso
de uso y la interacción entre ellos.
11/07/2021 51
4.1 Diagramas de casos de uso
• Muestran los actores, los casos de uso y la asociación
entre estos.
• Los actores son elementos externos al sistema y se
comunican con él por medio de asociaciones que
representan eventos de entrada/salida.
• Los casos de uso indican los procesos que hace el sistema.
• Los casos de uso están al servicio y resuelven las
necesidades de los actores.
• Un caso de uso contiene varias secuencias de actividades.
11/07/2021 52
Diagrama de casos de uso
ingresarAlSistema
login, password | "Bienvenido al sistema" OR "Credenciales equivocadas"

Persona consultarHorarioDeParaleloDeMate
ria
coMa, numPar | horario, "No existe materia" OR "No existe paralelo" <<include>>
<<include>>
consultarPrerrequisitoDeMateria verificarMateria
Estudiante
(from Logical View) <<include>>
primerNombre : String
segundoNombre : String
primerApellido : String
segundoApellido : String
direcciónDelDomicilio : String
teléfonoDelDomicilio : String registrarInscripciónEnUnaMateria
estadoCivil : char
fechaDeNacimiento : Date
sexo : char
género : char
teléfonoCelular : String
11/07/2021 53
4.2 Diagramas de Actividad
• Representan las secuencias de actividades de un caso de uso.
• Cada actividad es un tipo de estado.
• Contienen estados inicial y final.
• Se muestran las secuencias de las actividades.
• Se usan elementos que representan:
– Estado
– Actividad o acción
– Decisión
– Secuencia
– Calles (swimlanes)
– Barras para división y unión de actividades o acciones
11/07/2021 54
Diagrama de actividad
ingresarLogin
ingresarPassword
validarLogin
true false
¿login correcto?
validarPassword mostrarMensaje"Creden
ciales incorrectas"
false
true ¿password correcto?
mostrarMensaje"Bienve
nido al sistema"
11/07/2021 55
4.3 Diagramas de Secuencia
• Son un tipo de diagramas de interacción.
• Muestran de manera temporal los objetos y los
mensajes que intercambian los objetos dentro
de una secuencia de eventos de un caso de uso.
• Se representan objetos verticalmente y
mensajes entre objetos horizontalmente.
• Los mensajes poseen argumentos y son
llamados a funciones de otros objetos.
11/07/2021 56
Diagrama de secuencia para ingresar al
sistema con login y password correctos
: Usuario
: Estudiante
1: ingresarLogin(log:String)
2: ingresarPassword(pass:String)
3: verificarLogin():boolean
4: true
5: verificarPassword(String)
6: true
7: mostrarMensaje("Bienvenido al Sistema")
11/07/2021 57
Diagrama de secuencia para ingresar al
sistema con login incorrecto
: Usuario
: Estudiante
3: validarLogin():boolean
4: false
5: mostrarMensaje("Credenciales incorrectas")
11/07/2021 58
4.4 Diagramas de Colaboración
• También son un tipo de diagramas de
interacción.
• Muestran, de manera estructural, los objetos y
los mensajes que intercambian los objetos en
un caso de uso.
• Son iguales a los diagramas de secuencia, con la
diferencia de que los de secuencia muestran los
mensajes en el tiempo, mientras que los de
colaboración los muestran en el espacio.
11/07/2021 59
Diagrama de colaboración para login y
password correctos
3: verificarLogin():boolean
5: verificarPassword(String)
: Usuario
4: true
: Estudiante 6: true
7: mostrarMensaje("Bienvenido al Sistema")
11/07/2021 60
5. Reutilización de software
• Se estudian tres tipos de elementos
ampliamente usados en reutilización de
software:
– Patrones de diseño
– Componentes
– Refactorización
• La reutilización permite desarrollar software
más rápido, a menor costo y con mayor
confiabilidad y calidad.
11/07/2021 61
5.1 Patrones de diseño - Design Patterns
• El patrón es una descripción del problema y la esencia de
su solución, por lo que la solución puede reutilizarse en
diferentes configuraciones.
• El patrón no es una especificación detallada.
• Se la puede considerar como una descripción de sabiduría
y experiencia acumuladas: una solución bien probada a un
problema común.
• Los patrones y los lenguajes de patrón son formas de
describir mejores prácticas, buenos diseños, y captan la
experiencia de tal manera que es posible que otros
reutilicen esta experiencia.
11/07/2021 62
5.1 Patrones de diseño
• Se puede explicar el diseño al describir los
patrones que se utilizaron.
• Los patrones más conocidos los hicieron la
“Banda de los cuatro” en su libro de patrones.
• También constan en publicaciones realizadas
por autores de la compañía Siemens.
• Se asocian con el diseño orientado a objetos.
• Se apoyan en herencia y polimorfismo.
11/07/2021 63
5.1 Patrones de diseño
• Los cuatro elementos esenciales de los patrones de diseño, definidos
por la “Banda de los cuatro” en su libro son:
1. Un nombre que sea una referencia significativa al patrón.
2. Una descripción del área problemática que enuncie cuándo puede
aplicarse el patrón.
3. Una descripción de la solución de las partes de la solución del diseño,
sus relaciones y responsabilidades. Es una plantilla para que una
solución de diseño se instale en diferentes formas. Se expresa
gráficamente y muestra las relaciones entre los objetos y las clases de
objetos en la solución.
4. Un estado de las consecuencias, los resultados y las negociaciones al
aplicar el patrón. Ayuda a los diseñadores a entender si es factible usar
o no un patrón en una situación particular.
11/07/2021 64
5.2 Componentes
• Para desarrollar software orientado a componentes, se usa la
Ingeniería de Software Basada en Componentes (CBSE –
Component Based Software Engineering).
• Se basa en la reutilización de componentes de software.
• La CBSE es el proceso de definir, implementar e integrar o
componer los componentes independientes e imprecisos de
sistemas.
• La única forma de enfrentar la complejidad y entregar un mejor
software con mayor rapidez es reutilizar en lugar de implementar
una vez más componentes de software.
• La siguiente tabla muestra las características esenciales de un
componente como se usa en CBSE.
11/07/2021 65
Característica del componente Descripción
Estandarizado Estandarización de componentes significa que
un componente utilizado durante un proceso
CBSE debe ajustarse a un modelo de
componentes estándar. Este modelo puede
definir interfaces de componentes, metadatos
de componentes, documentación, composición
e implementación.
Un componente debe ser independiente; debe
Independiente ser factible componerlo e implementarlo sin
usar otros componentes específicos. En
situaciones en que el componente necesita
brindar servicios externos, esto debería
plantearse claramente en una especificación
de interfaz de “requiere”.
Para que un componente sea componible,
Componible todas las interacciones externas deben tener
lugar mediante interfaces definidas
públicamente. Además, debe permitir acceso
externo a información acerca de sí mismo, así
como a sus métodos y atributos.
11/07/2021 66
Característica del componente Descripción
Implementable Para que sea implementable, un componente
debe estar autocontenido. Debe ser capaz de
ejecutarse como entidad independiente en una
plataforma de componente que permita una
implementación del modelo de componentes.
Por lo general, esto significa que el
componente es binario y no tiene que
compilarse antes de su implementación. Si un
componente se implementa como servicio, no
tiene que implementarse por parte de un
usuario de un componente. En vez de ello, se
implementa por parte del proveedor del
servicio.
Documentado Los componentes deben implementarse por

completo, para que los usuarios potenciales
puedan decidir si los componentes cumplen o
no sus necesidades. Debe especificarse la
sintaxis y, de manera ideal, la semántica de
todas las interfaces de componente.
11/07/2021 67
5.3 Refactorización
• Es el mejoramiento de la estructura y organización de un
programa.
• Permite evitar la degeneración del código y la integración continua
de nueva funcionalidad.
• Ayuda en la reutilización puesto que la refactorización de
componentes en respuesta a los cambios suele ser relativamente
fácil.
• Ejemplos:
– reorganización de una jerarquía de clases para remover código duplicado.
– Ordenamiento y cambio de nombre de atributos y métodos
– Sustitución de código con llamadas a métodos definidos en la libraría de
un programa.
11/07/2021 68
6. Relación entre requerimientos, diseño y
arquitectura
6.1 Transformación de modelos, diseño de
contratos e invariantes.
- Transformación de modelos
- Los modelos que se elaboran van siendo
transformados conforme se avanza en el ciclo de
vida de desarrollo de software
- Los modelos iniciales tienen alta abstracción y
bajo detalle, mientras que los finales tendrán baja
abstracción y mayor nivel de detalle.
11/07/2021 69
6.1 Diseño de contratos
• Los «contratos» determinan lo que se debe
hacer conforme se avanza en el desarrollo del
sistema.
• Habrá ocasiones en que los contratos
determinen que los modelos no cambien, pero
habrá ocasiones en que se acepten cambios e
inclusive inclusiones o exclusiones de los
artefactos elaborados durante el proceso.
11/07/2021 70
6.1 Invariantes
• Las «invariantes» son elementos o componentes del software que
no cambian en el tiempo.
• Deben mantenerse para preservar principios fundamentales del
producto a elaborar.
• Pueden ser desde constantes hasta pre o pos condiciones que se
mantienen antes o después de un proceso.
• Ejemplo:
– antes de retirar dinero de una cuenta, el saldo de la cuenta debe ser mayor
o igual a cero
– después de retirar dinero de la cuenta, también el saldo debe ser mayor o
igual a cero.
– La invariante es que el saldo siempre debe ser mayor o igual a cero, tanto
antes como después de retirar dinero de una cuenta.
11/07/2021 71
6.2 Definición de arquitectura de software
• Una arquitectura de software es una

descripción de cómo se organiza un sistema
software.
• Las propiedades de un sistema, como
rendimiento, seguridad y disponibilidad están
influidas por la arquitectura utilizada.
• También se define como el modelo de la
estructura y organización fundamentales de un
sistema software.
11/07/2021 72
6.3 Arquitecturas estándares
• Se usa el concepto de patrón arquitectónico:
– descripción abstracta de una arquitectura de
software que se ensayó y puso a prueba en
algunos sistemas software distintos.
• La descripción del patrón incluye información
acerca de dónde es adecuado usar el patrón y
la organización de los componentes de la
arquitectura.
11/07/2021 73
• El estilo y la estructura arquitectónica que se
elijan para un sistema dependerán de los
requerimientos no funcionales del sistema:
1. Rendimiento:
– si es crítico, la arquitectura debe diseñarse para
localizar operaciones críticas dentro de un
pequeño número de componentes desplegados
en la misma computadora y no distribuidos por la
red.
11/07/2021 74
1. Rendimiento:
– Se debería usar algunos componentes
relativamente grandes, en vez de componentes
de grano fino, lo cual reduce el número de
comunicaciones entre componentes.
– También se puede considerar organizaciones del
sistema en tiempo de operación que lo permitan
ser replicable y ejecutable en diferentes
procesadores.
11/07/2021 75
2. Seguridad: capacidad del sistema para
protegerse contra intrusión accidental o
deliberada:
– Si es crítica, será necesario usar una estructura
en capas para la arquitectura, con los activos
críticos protegidos en las capas más internas, y
con un alto nivel de validación de seguridad
aplicado a dichas capas.
11/07/2021 76
3. Protección: capacidad del sistema para ejecutar sin
fallas catastróficas; es un juicio de cuán probable es que
el sistema causará daños a las personas o su ambiente:
– Si es crítico, la arquitectura debe diseñarse de modo que
las operaciones relacionadas con la protección se ubiquen
en algún componente individual o en un pequeño número
de componentes.
– Así se reducen los costos y problemas de validación de la
protección, y hace posible ofrecer sistemas de protección
relacionados que, en caso de falla, desactiven con
seguridad el sistema.
11/07/2021 77
4. Disponibilidad:
– Si es crítica, la arquitectura tiene que diseñarse
para incluir componentes redundantes de manera
que sea posible sustituir y actualizar componentes
sin detener el sistema.
– Se usan arquitecturas de sistemas tolerantes a
fallas en sistemas de alta disponibilidad.
11/07/2021 78
5. Mantenibilidad:
– Si es crítica, la arquitectura del sistema debe
diseñarse usando componentes autocontenidos
de grano fino que puedan cambiarse con facilidad.
– Los productores de datos tienen que separarse de
los consumidores y hay que evitar compartir las
estructuras de datos.
11/07/2021 79
• Existe conflicto potencial entre algunas de estas
arquitecturas.
• Por ejemplo, usar componentes grandes mejora el
rendimiento, pero utilizar componentes pequeños de
grano fino aumenta la mantenibilidad.
• Si tanto el rendimiento como la mantenibilidad son
requerimientos importantes, debe encontrarse algún
compromiso.
• Esto en ocasiones se logra usando diferentes patrones o
estilos arquitectónicos para distintas partes del sistema.
11/07/2021 80
7. Construcción de software
• Esta actividad combina la generación de
código (ya sea manual o automatizada) y las
pruebas que se requieren para descubrir
errores en éste.
11/07/2021 81
7.1 Prácticas de codificación
• Costumbres, hábitos, prácticas que utilizamos
cuando desarrollamos SW
– Al alcance de todos
– No ligadas a tecnologías concretas
• ¿Cuál es su finalidad?
– Mejorar el desarrollo de software
Código ofuscado
• Si nunca pensaríamos leer un titular como el
siguiente…
Código ofuscado (II)
• Porque codificamos del siguiente modo:
Fuente: New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1.5
http://java.sun.com/features/2003/05/bloch_qa.html
Código ofuscado (III)
• ¿Por ahorrar tiempo?
– El tiempo tecleando código es insignificante frente
al tiempo depurando
• Buscamos un código fácil de leer
– Los nombres deben de ser descriptivos
– Se debe emplear tiempo
• Escogiendo buenos nombres
• Tecleándolos 
• Renombrando los existentes
“The candy machine interface”
61 65
Interfaces de los métodos
• Apliquemos esta metáfora a las interfaces
que ofrecen las funciones/métodos
– Ejemplo: Función realloc() de ANSI C
-Cambia el tamaño del objeto apuntado por ptr al tamaño

especificado por tamanyo
-Si ptr es un puntero nulo, la función realloc se comporta a igual
que la función malloc para el tamaño especificado.
-Si el espacio no puede ser desadjudicado, el objeto apuntado por
ptr no varía.
-Si tamanyo es cero y ptr no es nulo, el objeto al que apunta es
liberado.
Interfaces de los métodos (II)
• Los métodos deben presentar un interfaz
extremadamente nítido
• Debe poder entenderse, sin consultar su
especificación
– Lo que el método hace
– Su Entrada/Salida
Interfaces de los métodos (III)
• Evitar parámetros que determinen el funcionamiento del
método
– Mejor hacer varios métodos. Ejemplo (clase String de Java)
•
•
• Evitar códigos de error
– Usar excepciones
• Evitar que null:
– Sea un parámetro “con significado”
– Sea un retorno “con significado” (salvo excepciones)
Código factorizado
Código sólido
• Es el código preparado para detectar errores
– No errores de usuario, sino errores que introducimos al
programar
• Cuando programamos codificaremos:
– Lo que el programa tiene que hacer
– Código “extra” para detectar errores
• Un ejemplo:
Asertos
• Pero lo anterior no es práctico: asertos
• Un aserto es un mecanismo
– Que permite hacer asunciones sobre el
funcionamiento de nuestro código
• Indican el error cuando no se validen
– Que puede activarse (desarrollo) y desactivarse
(lanzamiento)
• El código de comprobación puede y debe ser
tan complejo como sea necesario
Tipos de verificaciones
• Precondiciones
– Condiciones que debe cumplir el cliente para poder invocar un
método
• Sun no recomienda el uso de asertos: excepciones de
usuario específicas. Pero esto no es práctico.
• Invariantes
– Condiciones que deben validarse para considerar el estado del
objeto como legal
• Postcondiciones
– Condiciones que deben cumplirse después de la invocación a un
método
– Verifican que el método se ha comportado correctamente
Asertos en Java
• Usar sentencia assert (a partir de 1.4)
– Se habilita/deshabilita al ejecutar la aplicación
• Parámetro –ea de la VM
• Usar librería propia
– Permite sobrecargar los asertos para adaptarlos a
las comprobaciones más habituales
• Referencias no nulas
• Cadenas no vacías
Tests unitarios
• Un test unitario es un test que valida un módulo de un
programa
– Valida que funcione como es de esperar
• El testing debe ser sistemático
– Pruebas “bajo demanda”
• Implican asumir la corrección de lo que no probemos (ceguera)
• No se pueden repetir (trabajo tirado a la basura)
• No tiene nada que ver con los asertos del código sólido
– Pero se complementan
Tests unitarios (II)
• Los tests unitarios
– Deben ser auto comprobables
– Deben ser almacenados
• Para crecer a la vez que nuestros componentes
• Para poder ser ejecutados en el futuro
• Veremos un sencillo ejemplo en Java con Junit
– Pero es mucho más importante la práctica en sí
que la tecnología
Un ejemplo sencillo (I)
Un ejemplo sencillo (II)
¿Cómo afrontar el cambio?
• Anticipándonos a él
– Desarrollo en cascada
• Abrazándolo
– Desarrollo iterativo
– Manteniendo el código en su estado más sencillo
posible
• “Sencillo” distinto de “sofisticado”
• Se debe de volver continuamente sobre el código para
mejorar su diseño: refactoring
Refactoring
• Refactoring es cambiar la estructura interna del
código
– Mejorar su diseño
– Eliminar la duplicación
• Se presenta un catálogo de refactorings
– Replace error code with exception, Rename field,
Extract interface...
• Pero más importante es adoptar la actitud
– Mejorar el código siempre que se detecte la
necesidad
Composición mejor que herencia
• La herencia puede resultar tentadora como
mecanismo de reutilización de código
– Pero la herencia define una relación “es-un” entre
padre e hija
– La clase hija queda ligada a la clase padre: difícil
combinar funcionalidades
• La composición es una aproximación más
natural, por regla general
– Objetos que colaboran para lograr un fin
Conclusiones
• Todo el tiempo empleado en escribir
– Código fácil de leer
– Código robusto
– Tests unitarios
– Mejoras sobre el código existente
• Lo ganaremos con creces en calidad y velocidad de
desarrollo
• Las buenas prácticas están al alcance de cualquiera
– “I’m not an excellent programmer, I’m only a good programmer
with excellent habits”
Referencias
• Writing solid code. Steve Maguire. Microsoft Press, 1993.
• Refactoring: improving the design of existing code.
Martin Fowler. Addison Wesley, 1999.
• Extreme Programming explained: embrace change. Kent
Beck. Addison Wesley Professional, 2000.
• JUnit
– www.junit.org
• Catálogo de buenas prácticas en Java
– http://www.javapractices.com/index.cjp

Aplicaciones en Ambientes Propietarios 1 7

Cargado por

Copyright:

Formatos disponibles

Aplicaciones en Ambientes Propietarios 1 7

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Aplicaciones en Ambientes Propietarios 1 7

Cargado por

Copyright:

Formatos disponibles

APLICACIONES EN AMBIENTES

M.Sc. Ing. Marcos Raúl Córdova Bayas

- El diseño arquitectónico permite entender cómo debe organizarse

- En procesos ágiles, una de las primeras etapas en el

- Una especificación de un sistema no debe incluir cierta

- Las arquitecturas de software se diseñan en dos niveles de

- Ventajas de diseñar y documentar la arquitectura de

- La arquitectura de software sirve:

- Se modelan usando diagramas de bloques simples.

- Formas de utilización de un modelo arquitectónico:

- Tiene que ver con describir de manera completa los componentes de un

• Permite separar las competencias de un sistema en elementos independientes,

• Se define como el uso de un lenguaje de programación para ocultar la representación

• La cohesión implica que un módulo de un

Depositar(c:String, ve:float, vch:float)

login, password | "Bienvenido al sistema" OR "Credenciales equivocadas"

Documentado Los componentes deben implementarse por

• Una arquitectura de software es una

-Cambia el tamaño del objeto apuntado por ptr al tamaño

También podría gustarte