Materia: Arquitectura y diseo de Software I.T.S.A .

1.1.- Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos (ADOO) es un enfoque de la ingeniera de software que modela un sistema
como un grupo de objetos que interactan entre s. Este enfoque representa un dominio en trminos de conceptos
compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

En este mtodo de anlisis y diseo se crea un conjunto de modelos utilizando una notacin acordada como, por
ejemplo, el lenguaje unificado de modelado (UML). ADOO aplica tcnicas de modelado de objetos para analizar los
requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de mdulos de software - y para
disear una solucin para mejorar los procesos involucrados. No est restringido al diseo de programas de
computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologas de anlisis y diseo ms modernas
son casos de uso guiados a travs de requerimientos, diseo, implementacin, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estndar usado en anlisis y diseo
orientado a objetos.

Referencias Histricas
Definicin de Arquitectura y Diseo de Software

La Arquitectura de Software es una disciplina emergente del tpico general de diseo de software, relacionada con la
representacin y composicin de sistemas de software. En este contexto, el diseo de software se propone como una
actividad conciliatoria entre los requerimientos del problema, en trminos de una funcin, y la factibilidad de una
solucin en trminos de un sistema de software. La idea bsica es obtener una visin amplia, completa y humana del
software, como un producto tanto del conocimiento como de la intuicin del diseador de software.

Edsger Djikstra, 1968

Ciencias de la computacin como rama aplicada de las matemticas
Niveles de abstraccin
Stack, abrazos mortales, semforos, algoritmos de camino mas corto
NATO, 1968
F. L. Bauer Ingeniera de software

NATO, 1969
P. I. Sharp, Arquitectura de software

C. R. Spooner, 1971
Una arquitectura de software para los 70s
Referencia accidental

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 1

 Niklaus Wirth, 1971
Niveles de abstraccin, Stepwise refinement

DeRemer & Kron, 1976

Programming in the large

Fred Brooks, 1975 MMM

Diseador del OS/360, Premio Turing 2000
Arquitectura como interfaz usuario
El arquitecto es un agente del usuario, igual que quien disea su casa
Importancia de las estructuras de alto nivel y de decisiones tomadas al principio
Arquitectura: qu hacer Implementacin: cmo hacerlo

David Parnas
1972: Mdulos Ocultamiento de informacin
1974: Estructuras de software
1976: Familias de programas (rbol de decisin) Descomposicin Alternativa a diagramas de flujo,
propensin estructural (no funcional)
Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o
lo sern alguna vez) a los cuales es provechoso o til considerar como grupo. Esto evita el uso de
conceptos ambiguos tales como similitud funcional que surgen a veces cuando se describen
dominios. Por ejemplo, los ambientes de ingeniera de software y los juegos de video no se
consideran usualmente en el mismo dominio, aunque podran considerarse miembros de la misma
familia de programas en una discusin sobre herramientas que ayuden a construir interfaces graficas,
que ambos casualmente utilizan.

Dewayne Perry, Alexander Wolf 1992

Foundations for the study of software architecture
La dcada de 1990, creemos, ser la dcada de la arquitectura de software. Usamos el trmino
arquitectura en contraste con diseo, para evocar nociones de codificacin, de abstraccin, de
estndares, de entrenamiento formal (de los arquitectos de software) y de estilo. Es tiempo de re-
examinar el papel de la arquitectura de software en el contexto ms amplio del proceso de software
y de su administracin, as como sealar las nuevas tcnicas que han sido adoptadas.

Escuela de Carnegie Mellon (CMU-SEI)

Mary Shaw, David Garlan, Paul Clements, Robert Allen

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 2

1.2.1 Tcnicas de modelado de objetos (OMT)

Segn la Real Lengua Espaola: Tcnica: es Conjunto de procedimientos y recursos de que se sirve una ciencia o un
arte. Modelado: es una tcnica que ayuda a visualizar el sistema a construir. Objeto: Un objeto es una
representacin detallada, concreta y particular de un algo. Tal representacin determina su identidad, su estado y
su comportamiento particular en un momento dado.

En conclusin es Una serie de procedimientos para visualizar una serie de caracteristicas asignadas a un objeto.

Metodologa OMT (Tcnica de Modelado de Objetos):

Un modelo es una abstraccin de algo, con la finalidad de comprenderlo, antes de construirlo, ya que un modelo
omite los detalles no esenciales, es ms sencillo manejarlos, que manejar la entidad original.

OMT es una de las metodologas de anlisis y diseo orientadas a objetos, ms maduras y eficientes que existen en la
actualidad. La gran virtud que aporta esta metodologa es su carcter de abierta (no propietaria), que le permite ser
de dominio pblico y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolucin para acoplarse a
todas las necesidades actuales y futuras de la ingeniera de software.

Esta tcnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos, modelo dinmico y modelo
funcional.

El modelo de objetos.
El modelo de objetos es el modelo ms importante, ya que en l se identifican las clases dentro del sistema junto con
sus relaciones, as como sus atributos y operaciones, lo que representa la estructura esttica del sistema.

El modelo de objetos, representado en UML con Diagramas de Clase, describe la estructura de un sistema desde el
punto de vista de objetos y asociaciones.

El modelo dinmico.
Representa los aspectos temporales de comportamiento "de control" del sistema, mediante la secuencia de
operaciones en el tiempo.

El modelo dinmico, representado en UML con Diagramas de Secuencia, Diagramas de colaboracin, Diagramas de
Actividad y Diagramas de Estado, describe el comportamiento del sistema.

El modelo funcional.
Representa los aspectos transformacionales "de funcin" del sistema, mediante la transformacin de valores de los
datos. Se representa mediante un diagrama de flujo.

Cada modelo describe un aspecto del sistema pero contiene referencias a los dems modelos. Lo cual indica que los
tres no son totalmente independientes.

El modelo funcional, representado en UML con Diagramas de Caso de Uso, describe la funcionalidad del sistema
desde el punto de vista del usuario.

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 3

1.2.2 metodologa de Booch
La Metodologa de Booch es una tcnica usada en ingeniera de software. Es un lenguaje de modelado de objetos y
una metodologa ampliamente usada en el diseo de software orientado a objetos. Fue desarrollada por Grady Booch
mientras trabajaba para Rational Software (hoy parte de IBM).

Los aspectos notables de la metodologa de Booch han sido superados por el Lenguaje Unificado de Modelado, que
combina elementos grficos de la metodologa de Booch junto a elementos de la tcnica de modelado de objetos y la
Ingeniera de software orientada a objetos

Los aspectos metodolgicos de la metodologa de Booch fueron incorporados en varias metodologas y procesos,
siendo la principal de ellas el Proceso Racional Unificado (RUP).

1.3 Metodologia RUP (Rational Unified Process)

El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente resumido como RUP) es
un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa
estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al
contexto y necesidades de cada organizacin.

Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye
informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational
Method Composer (RMC), que permite la personalizacin de acuerdo con las necesidades.

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 4

Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms
detallada, el Rational Unified Process, que se vendiera como producto independiente.

RUP Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quin hace qu, cundo
y cmo).

RUP es el proceso de desarrollo ms general de los existentes actualmente.

Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus
estimaciones originales. Las iteraciones tempranas de proyectos conducidos RUP se enfocan fuertemente sobre
arquitectura del software; la puesta en prctica rpida de caractersticas se retrasa hasta que se ha identificado y se
ha probado una arquitectura firme.

RUP proporciona muchas ventajas sobre XP (METODOLOGIA EXTREME PROGRAMMING) le da nfasis en los
requisitos y el diseo.

La ventaja principal de RUP es que se basa todo en las mejores prcticas que se han intentado y se han probado en el
campo. (en comparacin con XP que se basa en las prcticas inestables que utilizaron juntas se evita que se derribe).

RUP se divide en cuatro fases:

Inicio (Define el alcance del proyecto)

Elaboracin (definicin, anlisis, diseo)
Construccin (implementacin)
Transicin (fin del proyecto y puesta en produccin)

Cada fase concluye con un HITO (T. Decisiones)

RUP realiza un levantamiento exhaustivo de requerimientos. Busca detectar defectos en las fases iniciales.
Intenta reducir al nmero de cambios tanto como sea posible. Realiza el Anlisis y diseo, tan completo como sea
posible. Diseo genrico, intenta anticiparse a futuras necesidades. Las necesidades de clientes no son fciles de
discernir.

Existe un contrato prefijado con los clientes.

El cliente interacta con el equipo de desarrollo mediante reuniones a diferencia de la metodologa XP que el cliente
es parte del equipo (in situ).

1.4 Diseo de alto nivel (HLD) y bajo nivel (LLD)

Diseo de Alto Nivel (DAN) es el diseo general del sistema que abarca la arquitectura del sistema y el diseo de
bases de datos. En l se describe la relacin entre los diferentes mdulos y las funciones del sistema. Flujo de datos,
diagramas de flujo y estructuras de datos estn cubiertos por la DAN. El diseo de alto nivel tambin identifica los
principales candidatos fuera de la plataforma de productos que pueden ser utilizados en el sistema.

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 5

 Alto nivel de diseo es la etapa de transicin entre los requisitos de los subsistemas y cmo la arquitectura y las
interfaces del sistema se implementarn para cumplir con los requisitos del sistema. Este proceso incluye la
descomposicin de los requisitos del sistema en las arquitecturas de proyecto alternativo y luego de la evaluacin de
estas arquitecturas de proyecto para un ptimo rendimiento, funcionalidad, costo, y otros asuntos tcnicos y no
tcnicos. Participacin de los interesados es fundamental para esta actividad. En este paso, las interfaces internas y
externas se identifican con los estndares de la industria es necesario.

Diseo de Bajo Nivel (LLD) es como detalla el Dilogo de Alto Nivel. Se define la lgica real de cada componente del
sistema. Los diagramas de clases con todos los mtodos y la relacin entre las clases estn bajo LLD. Especificaciones
de los programas estn cubiertas por LLD.

La funcionalidad de un diseo de bajo nivel es adaptar el diseo que anteriormente se ha realizado (diseo de alto
nivel) al lenguaje de programacin.

LLD describe todas y cada mdulo de forma elaborada de modo que el programador directamente el cdigo del
programa basado en este. Este ser por lo menos un documento para cada mdulo y puede haber ms de un mdulo.

La LLD contendr:

Detallada lgica funcional del mdulo en pseudocdigo - tablas de base de datos con todos los elementos
incluyendo su tipo y tamao
Todos los detalles de la interfaz con referencias completas de la API (ambas solicitudes y respuestas)
Todos los problemas de dependencia
El mensaje de error listados
Entrada completa y salidas de un mdulo

1.5 Compresin de los requerimientos

Se tiene que tener una completa comprensin de los requerimientos para poder resolver los problemas que se puedan
presentar as como para tener una participacin activa en el desarrollo del software. Si hay un equipo, esta
experiencia puede estar representada en diferentes miembros del grupo, pero al menos una persona debe poder
mantener la visin global del proyecto. Esta persona es el arquitecto del Software quien es el responsable de disear
la arquitectura del software, la cual incluye tomar las principales decisiones de diseo y la implementacin del
proyecto, se debe de tener experiencia en dominios tanto de problemas como de ingeniera de software.

Tipos de requerimientos

Requerimiento: Atributo del sistema

Algo que el sistema debe ser capaz de hacer para cumplir su propsito

Tipos clsicos de requerimientos:

o Funcionales: describen tareas especficas que el sistema debe ser capaz de hacer

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 6

 Ejemplo: imprimir cheques de sueldos

o No-funcionales (restricciones): limitan nuestras opciones para construir una solucin.

Ejemplo: generar cheques mx. 4 hrs despus de recibir listados de contabilidad

Analoga:
Requisitos funcionales: los verbos (Xear)

Requisitos no-funcionales: los adverbios (Xmente)

1.6 Casos de Uso

1.6.1 Introduccin
Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo
algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores. En el contexto
de ingeniera del software, un caso de uso es una secuencia de interacciones que se desarrollarn entre un sistema y
sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicacin y el comportamiento de un sistema mediante su interaccin con los
usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los casos de
uso en un sistema. Una relacin es una conexin entre los elementos del modelo, por ejemplo la especializacin y la
generalizacin son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al
mostrar cmo reacciona a eventos que se producen en su mbito o en l mismo.

La tcnica de caso de uso tiene xito en sistemas interactivos, ya que expresa la intencin que tiene el actor
(su usuario) al hacer uso del sistema.

Como tcnica de extraccin de requerimiento permite que el analista se centre en las necesidades del
usuario, qu espera ste lograr al utilizar el sistema, evitando que la gente especializada en informtica dirija la
funcionalidad del nuevo sistema basndose solamente en criterios tecnolgicos.

A su vez, durante la extraccin (elicitation en ingls), el analista se concentra en las tareas centrales del
usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la
priorizacin del requerimiento.

El diagrama de casos de uso representa la forma en cmo un Cliente (Actor) opera con el sistema en
desarrollo, adems de la forma, tipo y orden en como los elementos interactan (operaciones o casos de uso).

1.6.2 Elementos de Casos de uso.

Un diagrama de casos de uso consta de los siguientes elementos:

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 7

Actor:

Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante
destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una
persona en particular, sino ms bien la labor que realiza frente al sistema.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una
peticin de un actor o bien desde la invocacin desde otro caso de uso.

Relaciones:

Asociacin

Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso
de uso). Dicha relacin se denota con una flecha simple.

Dependencia o Instanciacin

Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se
instancia (se crea). Dicha relacin se denota con una flecha punteada.

Generalizacin

Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo,
que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relacin est orientado exclusivamente para casos de uso (y no para actores).

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 8

1.7 Modelos del Dominio
Modelo de Dominio:

Es un artefacto de la disciplina de anlisis, construido con las reglas de UML durante la fase de concepcin, en la tarea
construccin del modelo de dominio, presentado como uno o ms diagramas de clases y que contiene, no conceptos
propios de un sistema de software sino de la propia realidad fsica.

Los modelos de dominio pueden utilizarse para capturar y expresar el entendimiento ganado en un rea bajo anlisis
como paso previo al diseo de un sistema, ya sea de software o de otro tipo.

Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un
medio para comprender el sector industrial o de negocios al cual el sistema va a servir.

Los modelos de dominio pueden mostrar:

Objetos del dominio o clases conceptuales.

Asociaciones entre las clases conceptuales.
Atributos de las clases conceptuales.

Nota: Ejemplo de Modelo de Dominio

1.7.1 Visualizacin de Conceptos

La visualizacin de los conceptos en el principal propsito del diagrama de dominio, se enfoca en una serie de
conceptos como las asociaciones y los atributos que son vitales para este diagrama, para tener un mejor y fcil
entendimiento.

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 9

1.7.2 Aadir Asociaciones
Una asociacin representa una relacin entre clases, y aporta la semntica comn y la estructura de muchos tipos de
conexiones entre objetos.

Las asociaciones son los mecanismos que permite a los objetos comunicarse entre s; Describe la conexin entre
diferentes clases.

Las asociaciones pueden tener un papel que especifica el propsito de la asociacin y pueden ser unidireccionales o
bidireccionales (indicando si los dos objetos participantes en la relacin pueden intercambiar mensajes entre s, o es
nicamente uno de ellos el que recibe informacin del otro). Cada extremo de la asociacin tambin tiene un valor de
multiplicidad, que indica cuntos objetos de ese lado de la asociacin estn relacionados con un objeto del extremo
contrario.

1.7.3 Aadir Atributos

Un atributo no debera ser un concepto complejo sino que deberan ser cosas simples o tipos de datos. Por ejemplo:
fecha, hora, nmero, color, cdigo, descripcin, cantidad.

Cuando algo est compuesto de ms de un elemento, da la idea de estar frente a una entidad y no un atributo. Por
ejemplo, la direccin puede resultar un concepto simple pero en realidad est formada por calle, altura, etc.

Si una entidad puede tener muchos valores simultneos para un mismo atributo, ese atributo debera ser otra
entidad. Por ejemplo, una persona puede tener muchos nmeros de telfono, entonces nmero de telfono es una
entidad con una asociacin de 1 a muchos con la persona.

Una regla importante a tener en cuenta es relacionar las entidades con una asociacin y no a travs de un atributo.

No existe un nico diagrama de dominio correcto, todos sern una aproximacin del dominio que estamos
intentando entender. Un buen diagrama captura las abstracciones y da la informacin necesaria para entender el
contexto.

Unidad I: Introduccin Docente: M.I. Jose Yahveh Contreras Pgina 10