E

R
A
W
T
F
O
S
L
S
E
O
D
T
E
A
J
I
B
R
E
O
I
N
A
E
G
O
D
IN
A
T
N
E
I
OR

INGENIERA DEL SOFTWARE

El IEEE define:
Ingeniera es la aplicacin de un mtodo sistemtico, estructurado
y cuantificable a estructuras, mquinas, productos, sistemas o
procesos.
Ingeniera del software es la aplicacin de un mtodo sistemtico,
estructurado
y
cuantificable
al
desarrollo,
operacin
y
mantenimiento de software.
Bauer, 1972
La IS es el establecimiento y uso de slidos principios de ingeniera
y buenas prcticas de gestin, as como la evolucin de
herramientas y mtodos aplicables y su uso cuando sea apropiado
para obtener, dentro de las limitaciones de recursos existentes,
software que sea de alta calidad en un sentido explcitamente
definido.

PROGRAMACION ORIENTADO A
OBJETOS " POO "
Es una forma de pensar, una filosofa, de la cual surge una cultura
nueva que incorpora tcnicas y metodologas diferentes. desde el
punto de vista computacional "es un mtodo de implementacin en
el cul los programas son organizados como grupos cooperativos de
objetos, cada uno de los cuales representa una instancia de alguna
clase, y estas clases, todas son miembros de una jerarqua de clases
unidas va relaciones de herencia".

CONCEPTOS Y PRINCIPIOS
ORIENTADOS A OBJETOS
Vivimos en un mundo de objetos. Estos objetos existen en la
naturaleza, en entidades hechas por el hombre, en los negocios y en
los productos que usamos. Pueden ser clasificados, descritos,
organizados, combinados, manipulados y creados. Por esto no es,
sorprendente que se proponga una visin orientada a objetos para la
creacin de software de computadora, una abstraccin que modela el
mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor.
La primera vez que se propuso un enfoque orientado a objetos para
el desarrollo de software fue a finales de los aos sesenta. Sin
embargo, las tecnologas de objetos han necesitado casi veinte aos
para llegar a ser ampliamente usadas. Durante los aos 90. la
ingeniera del software orientada a objetos se convirti en el
paradigma de eleccin para muchos productores de software y para
un creciente nmero de sistemas de informacin y profesionales de la
ingeniera. A medida que pasa el tiempo, las tecnologas de objetos
estn sustituyendo a los enfoques clsicos de desarrollo de software.

El proceso
se mueve a travs de una espiral evolutiva que
comienza con la comunicacin con el usuario. Es aqu donde se
define el dominio del problema y se identifican las clases bsicas
del problema. La planificacin y el anlisis de riesgos establecen
una base para el plan del proyecto OO. El trabajo tcnico asociado
con la ingeniera del software sigue el camino iterativo mostrado en
la caja sombreada. La ingeniera del software hace hincapi en la
reutilizacin. Por lo tanto, las clases se buscan en una biblioteca (de
clases existentes) antes de construirse. Cuando una clase no puede
encontrarse en la biblioteca, el desarrollador de software aplica
Anlisis orientado a objetos (AOO), diseo orientado a objetos
(DOO), programacin orientada a objetos (POO) y pruebas
orientadas a objetos (PROO) para crear la clase y los objetos
derivados de la clase. La nueva clase se pone en la biblioteca de tal
manera que pueda ser reutilizada en el futuro.

MODELO DE PROCESO DE
OO

ORIENTADO A OBJETOS
Para entender la visin orientada a objetos, consideremos un
ejemplo de un objeto del mundo real cosa sobre la que usted est
sentado ahora una silla. Silla es un miembro (el trmino instancia
tambin se usa) de una clase mucho ms grande de objetos que
llamaremos Mobiliario. Un conjunto de atributos genricos puede
asociarse con cada objeto, en la clase Mobiliario. Por ejemplo,
todo mueble tiene un costo, dimensiones, peso, localizacin y
color, entre otros muchos posibles atributos. Estos son aplicables a
cualquier elemento sobre el que se hable, una mesa o silla, un sof
o un armario. Como Silla es un miembro de la clase Mobiliario,
hereda todos los atributos definidos para dicha clase.

Una vez definida la clase, los atributos pueden reutilizarse al crear

nuevas instancias de la clase. Por ejemplo, supongamos que
debemos definir un nuevo objeto llamado MESA que es un
miembro de la clase Mobiliario. La hereda todos los atributos de
Mobiliario.

Secuencia tpica de un proceso para un

proyecto OO.

A
T
N
E
I
R
O
S
O
S
I
T
S
E
I
J
L
B
A
O
N
A
A

O
D

El propsito del AOO es definir todas las clases que son relevantes al
problema que se va a resolver, las operaciones y atributos las
relaciones y comportamientos asociadas con ellas. Para cumplirlo se
deben ejecutar las siguientes tareas:

1.Los requisitos bsicos del usuario deben comunicarse entre el

cliente y el ingeniero del software.
2. Identificar las clases (es decir, definir atributos y mtodos).
3. Se debe especificar una jerarqua de clases.
4. Representan las relaciones objeto a objeto (conexiones de objetos).
5. Modelar el comportamiento del objeto.
6. Repetir iterativamente las tareas de la 1 a la 5 hasta completar el
modelo.
El objetivo del anlisis orientado a objetos es desarrollar una serie de
modelos que describan el software de computadora al trabajar para
satisfacer un conjunto de requisitos definidos por el cliente. El AOO,
como los mtodos de anlisis convencional , forman un modelo de
anlisis multiparte para satisfacer este objetivo.

El panorama del AOO

La popularidad de las tecnologas de objetos ha generado docenas de
mtodos de desde finales de los 80 y durante los 90'. Cada uno de
ellos introduce un proceso para el anlisis de un producto o sistema,
un conjunto de modelos que evoluciona fuera del proceso, y una
notacin que posibilita al ingeniero del software crear cada modelo de
una manera consistente. Entre los ms ampliamente utilizados se
encuentran:
El mtodo de Wirfs-Brock. El mtodo de Brock no hace una
distincin clara entre las tareas de anlisis y diseo. En su lugar,
propone un proceso continuo que comienza con la valoracin de una
especificacin del cliente y termina con el diseo. A continuacin se
esbozan brevemente las tareas relacionadas con el anlisis de WirfsBrock:
1. Evaluar la especificacin del cliente.
2.Usar un anlisis gramatical para extraer clases candidatas de la
especificacin.
3.Agrupar las clases en un intento de determinar clases.
4.Definir
responsabilidades
para
cada
clase.
Asignar
responsabilidades a cada clase. 5.Identificar relaciones entre clases.
6.Definir
colaboraciones
entre
clases
basndose
en
sus

El mtodo de Booch. El mtodo de Booch

abarca un
microproceso de desarrollo y un macroproceso de desarrollo. El
nivel micro define un conjunto de tareas de anlisis que se reaplican
en cada etapa en el macro proceso. Por esto se mantienen un
enfoque evolutivo. El micro proceso de desarrollo identifica clases y
objetos y la semntica de dichas clases y objetos, define las
relaciones entre clases y objetos y realiza una serie de refinamientos
para elaborar el modelo del anlisis.
El mtodo de Rumbaugh. Rumbaugh
y sus colegas
desarrollaron la Tcnica de Modelado Objetos (OMT) para el anlisis,
diseo del sistema y diseo a nivel de objetos. La actividad de
anlisis crea tres modelos: el modelo de objetos (una representacin
de objetos, clases, jerarquas y relaciones), el modelo dinmico (una
representacin del comportamiento del sistema y los objetos) y el
modelo funcional (una representacin a alto nivel del flujo de
informacin a travs del sistema similar al DFD).
El mtodo de Jacobson. Tambin llamado OOSE (en espaol
Ingeniera del Software Orientada a Objetos), el mtodo de Jacobson
es una versin simplificada de Objectory, un mtodo patentado,
tambin desarrollado por Jacobson. Este mtodo se diferencia de los

El mtodo de Coad y Yourdon. El mtodo de Coad y Yourdon se

considera, con frecuencia, como uno de los mtodos del ms sencillos
de aprender. La notacin del modelado es relativamente simple y las
reglas para desarrollar el modelo de anlisis son evidentes. A
continuacin sigue una descripcin resumida del proceso de AOO de
Coad y Yourdon:
Identificar objetos, usando el criterio de que buscar.
Definir una estructura de generalizacin - especificacin.

ANALISIS DEL DOMINIO

El anlisis en sistemas orientados a objetos puede ocurrir a muchos
niveles diferentes de abstraccin. A nivel de negocios o empresas,
las tcnicas asociadas con el pueden acoplarse con un enfoque de
ingeniera de la informacin en un esfuerzo por definir clases,
objetos, relaciones y comportamientos que modelen el negocio por
completo. A nivel de reas de negocios, puede definirse un modelo
de objetos que describa el trabajo de un rea especfica de negocios
(o una categora de productos o sistemas). A nivel de las
aplicaciones, el modelo de objetos se centra en los requisitos
especficos del cliente, pues stos afectan a la aplicacin que se va
a construir.
Anlisis de reutilizacin y del dominio
Las tecnologas de objetos estn influenciadas por la reutilizacin.
Considere un ejemplo simple. El anlisis de los requisitos para
nuevas aplicaciones indican la necesidad de 100 clases. Se le asigna
a dos equipos la tarea de construir la aplicacin. Cada uno debe
disear y construir un producto final y, a su vez, est compuesto de
personas con el mismo nivel de habilidad y experiencia.

EL PROCESO DE ANLISIS DEL DOMINIO

Firesmith describe el anlisis del dominio del software de la siguiente
manera:

El anlisis del dominio del software es la identificacin, anlisis y

especificacin de requisitos comunes de un dominio de aplicacin
especfico, normalmente para su reutilizacin en mltiples proyectos
dentro del mismo dominio de aplicacin ... (el anlisis orientado a
objetos del dominio es la identificacin, anlisis y especificacin de
capacidades comunes y reutilizables dentro de un dominio de
aplicacin especfico, en trminos de objetos, clases, submontajes y
marcos de trabajo comunes.

O
D
A
T
N
E
I
R
O
S
O
O
T

E
E
J
S
B
O
DI
A

1) A
diferencia de los mtodos de diseo de software
convencionales, el DOO proporciona un diseo que alcanza
diferentes niveles de modularidad. La mayora de los
componentes de un sistema, estn organizados en subsistemas,
un mdulo a nivel del sistema. Los datos y las operaciones que
manipulan los datos se encapsulan en objetos , una forma
modular que es el bloque de construccin de un sistema 00.
Adems, el DOO debe describir la organizacin especfica de los
datos de los atributos y el detalle procedural de cada operacin.
Estos representan datos y piezas algortmicas de un sistema OO
y son los que contribuyen a la modularidad global.
2) El diseo de software orientado a objetos es difcil, y el diseo de
software reusable orientado a objetos es aun ms difcil. Se deben
identificar los objetos pertinentes, clasificarlos dentro de las clases
en la granularidad correcta, definir interfaces de clases y jerarquas
de herencia y establecer relaciones clave entre ellos. El diseo debe
ser especfico al problema que se tiene entre manos, pero
suficientemente
general para adaptarse a problemas
y
requerimientos futuros. Adems se deber evitar el rediseo, o por
lo menos Los diseadores experimentados en OO dicen que un
diseo reusable y flexible es difcil, si no imposible de obtener
bien, la primera vez. Antes de que un diseo sea terminado,
usualmente tratan de varias veces, modificndolo cada vez.

LAS CUATRO CAPAS DE LA PIRMIDE DE

DISEO SON:
1) La capa subsistema. Contiene una representacin de cada uno de
los subsistemas, para permitir al software conseguir sus requisitos
definidos por el cliente e implementar la infraestructura que soporte
los requerimientos del cliente.
2) La capa de clases y objetos. Contiene la jerarqua de clases, que
permiten al sistema ser creado usando generalizaciones y cada vez
especializaciones ms acertadas. Esta capa tambin contiene
representaciones.
3) La capa de mensajes. Contiene detalles de diseo, que permite a
cada objeto comunicarse con sus colaboradores. Esta capa establece
interfaces externas e internas para el sistema.
4) La capa de responsabilidades. Contiene estructuras de datos y
diseos algortmicos, para todos los atributos y operaciones de cada
objeto.

LA PIRMIDE DEL DISEO OO

ENFOQUE CONVENCIONAL VS OO
Los enfoques convencionales para el diseo de software aplican
distintas notaciones y conjunto de heursticas, para trazar el
modelo de anlisis en un modelo de diseo cada elemento del
modelo convencional de anlisis se corresponde con uno o ms
capas del modelo de diseo. Al igual que el diseo convencional
de software, el aplica el diseo de datos cuando los atributos
son representados, el diseo de interfaz cuando se desarrolla un
modelo de mensajera, y diseo a nivel de componentes
mental), para operaciones de diseo. Es importante notar que la
arquitectura de un diseo tiene ms que ver con la colaboracin
entre objetos que con el control de flujo entre componentes del
sistema.

ASPECTOS DEL DISEO

1) Descomponibilidad: la facilidad con que un mtodo de diseo
ayuda al diseador a descomponer un problema grande en
problemas ms pequeos, hacindolos ms fcil de resolver.
2) Componibilidad: el grado con el que un mtodo de diseo asegura
que los componentes del programa (mdulos), una vez diseados y
construidos, pueden ser reutilizados para crear otros sistemas.
3) Comprensibilidad: la facilidad con la que el componente de un
programa puede ser entendido, sin hacer referencia a otra
informacin o mdulos.
4) Continuidad: la habilidad para hacer pequeos cambios en un
programa y que se
revelen haciendo los cambios pertinentes
en uno o muy pocos mdulos.
5) Proteccin: una
propagacin de
mdulo dado.

caracterstica arquitectnica, que reduce la

efectos colaterales, si ocurre un error en un

EL PANORAMA DE DOO
El mtodo de Booch: abarca un proceso demicro desarrollo y un
proceso de macro desarrollo. En el contexto del diseo, el macro
desarrollo engloba una actividad de planificacin arquitectnica,
que agrupa objetos similares en particiones arquitectnicas
separadas, capas de objetos por nivel de abstraccin, identifica
situaciones relevantes, crea un prototipo de diseo y valida el
prototipo aplicndolo a situaciones de uso. El micro desarrollo
define un conjunto de reglas que regulan el uso de operaciones y
atributos y las polticas del dominio especfico para la
administracin de la memoria, manejo de errores y otras funciones;
desarrolla situaciones que describen la semntica de las reglas y
polticas; crea un prototipo para cada poltica; instrumenta y refina
El mtodo de Rumbaugh: engloba una actividad de diseo que
el prototipo; y revisa cada poltica para as transmitir su visin
alienta al diseo a ser conducido a dos diferentes niveles de
arquitectnica.
abstraccin. El
de sistema se centra en el esquema de los
componentes que se necesitan para construir un sistema o producto
completo

El mtodo de Jacobson: El diseo para ISOO (Ingeniera del

software orientada a objetos), es una versin simplificada del mtodo
propietario Objectory, tambin desarrollado por Jacobson. El modelo
de diseo enfatiza la planificacin para el modelo de anlisis ISOO. En
principio, el modelo idealizado de anlisis se adapta para acoplarse
al ambiente
del mundo real.
Despus los objetos de diseo
primarios, llamados bloques,
son creados y catalogados como
bloques de interfaz, bloques de entidades y bloques de control.
El mtodo de Coad y Yourdon: se desarroll estudiando cmo es
que los diseadores orientados a objetos efectivos hacen su trabajo.
La aproximacin de diseo dirige no slo la aplicacin, sino tambin
la infraestructura de la aplicacin, y se enfoca en la representacin
de cuatro componentes mayores de sistemas: la componente de
dominio del problema, la componente de interaccin humana, la
componente de administracin de tareas y la de administracin de
datos.
El mtodo de Wirfs-Brock: definen un conjunto de tareas tcnicas,
en la cual el anlisis conduce sin duda al diseo. Los protocolos3 para
cada clase se construyen refinando contratos entre objetos. Cada
operacin (responsabilidad) y protocolo (diseo de interfaz) se disea
hasta un nivel de detalle que guiar la implementacin. Se desarrollan
las especificaciones para cada clase (definir responsabilidades
privadas y detalles de operaciones) y cada subsistema (identificar las

ETAPAS DEL DOO

1. Describir cada subsistema y asignar a procesadores y tareas.
2. Elegir una estrategia para implementar la administracin de
datos, soporte de interfaz y administracin de tareas.
3. Disear un mecanismo de control, para el sistema apropiado.

4. Disear objetos creando una representacin procedural para

cada operacin, y estructuras de datos para los atributos de clase.
5. Disear mensajes, usando la colaboracin entre objetos y
relaciones.
6. Crear el modelo de mensajera.
7. Revisar el modelo de diseo y renovarlo cada vez que se
requiera.

FLUJO DE PROCESO PARA DOO

EL PROCESO DE DISEO DE
SISTEMA
El proceso de diseo del sistema abarca las siguientes
actividades:

Particin del modelo de anlisis en subsistemas.

Identificar la concurrencia dictada por el problema.
Asignar subsistemas a procesadores y tareas.
Desarrollar un diseo para la interfaz de usuario.
Elegir una estrategia bsica para implementar
la
administracin (gestin) de datos.
Identificar recursos globales y los mecanismos de control
requeridos para su acceso.
Disear un mecanismo de control apropiado para el sistema,
incluyendo administracin de tareas.
Considerar cmo deben manejarse las condiciones de frontera.
Revisar y considerar Trade-offs.

PROCESO DE DISEO DE OBJETOS

El diseo de objetos tiene que ver con el diseo detallado de los
objetos y sus interacciones. Se completa dentro de la arquitectura
global, definida durante el diseo del sistema y de acuerdo con las
reglas y protocolos de diseo aceptados. El diseo del objeto est
relacionado en particular con la especificacin de los tipos de
atributos, cmo funcionan las operaciones y cmo los objetos se
enlazan con otros objetos.
Actividades:
Descripcin de objetos
Diseo de algoritmos y estructuras de datos

PATRONES DE DISEO
Se encontrarn patrones repetidos de clases y objetos de
comunicacin, en muchos sistemas orientados a objetos. Estos
patrones resuelven problemas especficos de diseo , y vuelven al
diseo orientado a objetos ms flexible, elegante y extremadamente
reutilizable. Ayudan a los diseadores a reutilizar diseos exitosos
basando nuevos diseos en experiencia previa.
En la actualidad, se ha desarrollado y catalogado un nmero
relativamente pequeo de patrones. De cualquier manera, los ltimos
cinco aos han sido testigos de una tremenda explosin, en
trminos
de inters industrial. Los patrones, junto con los
componentes, ofrecen la esperanza de que la ingeniera de software,
eventualmente, se parezca a otras disciplinas de ingeniera, con
clases volvindose el anlogo en software de componentes
electrnicos, y los patrones volvindose el anlogo en software de
pequeos circuitos hechos de componentes.

S
A

R
P

D
A
T
N
S
E
I
O
T
R
O BJE
S
O
A
B
A
E
U

EL objetivo de las pruebas, expresado de forma sencilla, es encontrar

el mayor nmero posible de errores con una cantidad razonable de
esfuerzo, aplicado sobre un lapso de tiempo realista.
A pesar de que este objetivo fundamental permanece inalterado para
el software orientado a objetos, la naturaleza de los programas OO
cambian las estrategias y las tcticas de prueba.
La prueba de los sistemas OO presentan un nuevo conjunto de retos
al ingeniero del software. La definicin de pruebas debe ser ampliada
para incluir tcnicas que descubran errores (revisiones tcnicas
formales), aplicadas para los modelos de A00 y DOO. La integridad,
complecin y consistencia de las representaciones O0 deben ser
evaluadas conforme se construyen. Las pruebas de unidad pierden
mucho de su significado, y las estrategias de integracin cambian de
modo significativo. En resumen, las estrategias y tcticas de prueba
deben tomarse en cuenta para las caractersticas propias del
software OO.

PRUEBAS DE LOS MODELOS DE AOO Y DOO

Los modelos de anlisis y diseo no pueden probarse en el sentido
convencional, ya que no pueden ejecutarse. Sin embargo, se pueden
utilizar las revisiones tcnicas formales para examinar la exactitud y
consistencia de ambos modelos de anlisis y diseo.
Exactitud de los modelos de AOO y DOO
La notacin y sintaxis que se utiliza para representar los modelos de
anlisis y diseo se corresponder con el mtodo especfico de
anlisis y diseo, elegido para el proyecto. Por consiguiente, la
exactitud sintctica se juzga en el uso apropiado de la simbologa;
cada modelo se revisa para asegurarse de que se han mantenido las
convenciones propias del modelado. Durante el anlisis y diseo, la
exactitud semntica debe juzgarse basada en la conformidad del
modelo con el dominio del problema en el mundo real. Si el modelo
refleja con exactitud el mundo real (al nivel de detalle apropiado a la
etapa de desarrollo en la que se revisa el modelo), entonces es
semnticamente correcto. Para determinar si el modelo en realidad
refleja el mundo real, debe presentarse a expertos en el dominio del
problema, quienes examinarn las definiciones de las clases y sus
jerarquas, para detectar omisiones o ambigedades. Las relaciones
entre clases (conexiones de instancia) se evalan para determinar si

Consistencia de los modelos de AOO

La consistencia de los modelos de A OO y DOO debe juzgarse
considerando las relaciones entre entidades dentro del modelo. Un
modelo inconsistente tiene representaciones en una parte, que no se
reflejan correctamente en otras partes del modelo .
ESTRATEGIAS DE PRUEBAS ORIENTADAS A OBJETOS
La estrategia clsica para la prueba de software de ordenador,
comienza con probar lo pequeo y funciona hacia fuera haciendo
probar lo grande. Siguiendo la jerga de la prueba de software , se
comienza con las pruebas de unidad, despus se progresa hacia las
pruebas de integracin y se culmina con las pruebas de validacin del
sistema. En aplicaciones convencionales, las pruebas de unidad se
centran en las unidades de programa compilables ms pequeas el
subprograma (por ejemplo, mdulo, subrutina, procedimiento,
componente). Una vez que cada una de estas unidades han sido
probadas individualmente, se integran en una estructura de
programa, mientras que se ejecutan una serie de pruebas de
regresin para descubrir errores, debidos a las interfaces entre los
mdulos y los efectos colaterales producidos por aadir nuevas
unidades. Por ltimo, el sistema se comprueba como un todo para

Las pruebas de unidad en el contexto de la OO

Cuando se considera el software orientado a objetos, el concepto de
unidad cambia. La encapsulacin conduce a la definicin de clases y
objetos. Esto significa que cada clase y cada instancia de una clase
(objeto), envuelven atributos (datos) y operaciones (tambin
conocidos como mtodos o servicios), que manipulan estos datos. En
vez de probar un mdulo individual, la unidad ms pequea
comprobable es la clase u objeto encapsulado. Ya que una clase
puede contener un nmero de operaciones diferentes, y una
operacin particular debe existir como parte de un nmero de clases
diferentes, el significado de la unidad de prueba cambia
drsticamente.
Las pruebas de integracin en el contexto OO
Ya que el software orientado a objetos no tiene una estructura de
control jerrquico, las estrategias convencionales de integracin
descendente (top-down) y ascendente (bottom-up) tienen muy poco
significado. En suma, la integracin de operaciones una por una en
una clase (la aproximacin de la integracin incremental
convencional), a menudo es imposible por la interaccin directa e
indirecta de los componentes que conforman la clase.

S
A

C
I
N
C
S
S

A
O
T
T
M
E
S
E
J
A
T
B
C
S
I
I
O
S
R
A
T
A

S
R
O
M PA
D
A
T
N
E
I
R
O

las mtricas y mediciones son componentes clave para cualquier

disciplina de ingeniera y la ingeniera de software orientada a
objetos no es una excepcin. Desgraciadamente, el uso de mtricas
para sistemas O0 ha progresado mucho ms despacio que el uso de
otros mtodos OO.
Ed Berard menciono que :
desconfan de cualquier cosa que parezca o suene a medicin. Son
rpidos, bastante rpidos para sealar las imperfecciones, en los
argumentos de cualquiera que hable acerca de las mediciones a los
productos de software, procesos de software, y especialmente
personas involucradas en software.
Estas mediciones son tiles ya que nos permiten al ingeniero evaluar
el software al inicio del proceso, haciendo cambios que reducirn la
complejidad y mejorarn la viabilidad, a largo plazo, del producto
final.

EL PROPSITO DE LAS MTRICAS

ORIENTADAS A OBJETOS
Los objetivos primarios para las mtricas orientadas a objetos no son
diferentes de aquellos de las mtricas desarrolladas para el software
convencional:
para entender mejor la calidad del producto.
para evaluar la efectividad del proceso.
para mejorar la calidad del trabajo llevado a Cabo al nivel del
proyecto.

! Gracia
s