Arquitetura de Software Baseada em Componentes:

Um estudo de caso para um Sistema de Gerenciamento de Solicitaes de Muncipes

Aline da Cruz Rodrigues Souza

Dep. de Cincia da Computao e Instituto de Tecnologia
Universidade Federal Fluminense (UFF)
Rio das Ostras, Brasil
acrsouza@id.uff.br

Resumo O seguinte trabalho se baseia no estudo de

arquitetura de software baseada em componentes e a aplicao
dos conceitos aprendidos em uma tarefa prtica de especificao
de componentes e suas interfaces.
Palavras-chave Arquitetura de software baseada em
componentes,
softwares
baseados
em
componentes,
componentizao.

I. INTRODUCO
Este trabalho consiste no estudo sobre arquitetura de
software baseada em componentes de acordo com o livro UML
Components: A simple Process for Specifying ComponentBased Software [1]. Com base no livro a atividade proposta foi
trabalhar os conceitos aprendidos na disciplina de Tpicos
Especiais em Arquitetura de Software e utilizar a
componentizao de maneira prtica e com um problema real.
Como exemplificao para o estudo proposto discutido a
componentizao de um sistema Web que gerencia solicitaes
diversas em uma prefeitura de uma determinada cidade da
Regio dos Lagos. Ou seja, a proposta realizar um estudo de
caso sobre um sistema de gerenciamento de solicitaes de
muncipes a uma prefeitura de um determinado municpio.
A problematizao segue o seguinte pressuposto: Um
cidado ou simplesmente Solicitante entra com um pedido no
sistema, tal qual um servio de poda de rvore, um conserto ou
melhoria em sua rua ou bairro, etc. Existe um atendente que o
auxilia no processo de pedidos. O cidado realiza a solicitao
que relacionada a um determinado Assunto. Ao realizar uma
solicitao o cidado receber como comprovante uma
mensagem via e-mail ou SMS. Cada solicitao verificada e
encaminhada para um determinado setor na prefeitura. Cada
Setor pertence a um determinado Departamento e cada
Departamento pertence a uma determinada Unidade. Quem
acompanha o Andamento desse processo o Atendente. As
solicitaes devem estar relacionadas a um Ttulo (muncipe,
servidor, vereador, etc) indicando o papel que o solicitante
assume ao realizar a solicitao. Cada ttulo est associado a
uma Prioridade padro, mas esta prioridade pode ser alterada
pelo Atendente, se ele assim desejar.
A partir do estudo de caso, sero realizadas as tarefas de
especificao com o intuito de entender melhor o sistema e

Gioliano Barbosa Bertoni

Dep. de Cincia da Computao e Instituto de Tecnologia
Universidade Federal Fluminense (UFF)
Rio das Ostras, Brasil
giolisb@hotmail.com
definir quais sero os componentes e suas respectivas
interfaces. Vale salientar que o cerne do trabalho estudar as
especificaes e desenvolver os modelos necessrios e refinlos at o ponto de obtermos os componentes e suas interfaces,
portanto, no se trata de um trabalho de implementao.
II. ARQUITETURA DE SOFTWARE
De acordo com Bass, Clements e Kazman [2] a Arquitetura
de Software de um programa ou sistema computacional a
estrutura ou estruturas dos sistemas que abrange os
componentes de software, as propriedades externamente
visveis desses componentes e as relaes entre eles. So
elencadas trs razes-chave sobre sua importncia:

As representaes das arquiteturas de software so

facilitadores na comunicao de todas as partes
interessadas no desenvolvimento de um sistema.

Arquitetura implica nas decises iniciadas na fase de

projeto que tero repercusso no trabalho de
engenharia de software, bem como sucesso na fase
final do sistema.

A arquitetura tida como um modelo relativamente

pequeno, intelectualmente inteligvel de como o
sistema estruturado e como seus componentes
trabalham em conjunto[2].
Atravs de uma viso mais ampla a arquitetura no
constitui no produto desenvolvido, o software em fase
operacional, e sim a representao que o engenheiro de
software usa para analisar a efetividade do projeto e na
satisfao dos respectivos requisitos, enaltecendo as
alternativas dado um estgio em que as mudanas em fases de
projeto so facilmente contornveis e possibilita a reduo dos
custos.
III. SISTEMAS DE COMPONENTES
Sistemas de componentes aderem ao princpio de dividir e
conquistar para o adequado gerenciamento da complexidade,
procurando romper a dificuldade nas fases de desenvolvimento
por meio da resoluo dos problemas, de modo geral, em
problemas menores, ou seja, a resoluo desses pequenos
pedaos facilita o entendimento por parte dos envolvidos no
processo e permite a construo de solues mais elaboradas.
Vale salientar que os componentes seguem a ideia de
combinar as funes e os dados associados a uma nica

unidade. Abordagens estruturadas tradicionais tendem a se

concentrar principalmente na decomposio funcional e tm
mantido uma forte diferenciao entre dados e funo.
Ressalta-se que um dos grandes desafios dessa abordagem a
gesto de mudanas. A partir desse pressuposto necessrio a
ideia de desenvolver para a mudana nas fases de estruturao
e projeto, bem como a gerncia das dependncias que iro
surgir ao longo do tempo.
Um dos objetivos substanciais da utilizao dos
componentes reutilizao. A partir de algo previamente bem
projetado e embasado, provvel que este mesmo artefato seja
utilizado posteriormente, porm em diferentes contextos,
objetivando consequentemente grande produtividade, melhoria
da qualidade e assim por diante. De fato com a
componentizao possvel o reuso, apesar de no ser uma
tarefa trivial. Deve-se atentar para problemas maiores, tais
como mudanas contnuas que dificultam uma maior
usabilidade bem como futuras substituies. Em suma, a
concentrao deve estar focada no mbito geral, ao invs de
partes. Outro ponto bastante difundido a ideia de
encapsulamento que oculta as funes implementadas e os
dados a serem armazenados nos componentes, visando o a
gerncia da complexidade.
Componentes estender princpios de objetos por meio da
composio da noo de uma classificao de objetos com
representaes explcitas de especificao de dependncia
chamadas Interfaces. Essas especificaes das capacidades
totais de um objeto podem ser divididas em vrias interfaces.
O desenvolvimento baseado em componentes trata a
separao de especificao de componente de aplicao e na
diviso das especificaes dos componentes em interfaces.
Especificaes dos componentes dividem-se em uma ou mais
interfaces e as dependncias intercomponentes pode ser restrita
a interfaces individuais. Possibilitando a reduo dos impactos
inerentes s mudanas, devido a um componente ter a
capacidade de substituir outro quando for necessrio, mesmo
que tenha especificaes distintas.
A especificao dos componentes importante para sua
perspectiva de montagem vista pelo prisma de
interdependncia entre as partes. Nesse mbito necessria
uma descrio mais abrangente de formas de componentes,
demonstradas na lista abaixo:
Especificao de Componentes: A especificao de
uma unidade de software descreve o comportamento
de um conjunto de Objetos Componentes e define a
unidade de implementao. O comportamento
definido como um conjunto de Interfaces. Uma
especificao de componentes realizada como um
Componente de Implementao.
Interface de Componente: A definio de um
conjunto de comportamentos que podem ser oferecidos
por um Objeto de Componente.
Componente de Implementao: A realizao de
uma Especificao de Componentes, a qual
independentemente desenvolvida. Ou seja, pode ser
instalada ou removida independentemente de outros
componentes.

Componentes Instalados: uma cpia instalada

(desenvolvida) da Implementao. O componente se
encontra em uso. Um componente instalado pode ter
mltiplos objetos componentes
Objeto Componente:
uma instncia de um
componente instalado. Um conceito em tempo de
tempo de execuo. Um objeto com os prprios dados
e uma nica identidade.
IV. ARQUITETURA DE COMPONENTES

vista como um conjunto de componentes de software,

suas relaes estruturais, e seu comportamento bem como as
dependncias. Esta uma definio lgica e independente do
nvel de tecnologia em que ser implantado. A arquitetura de
componentes pode ser aplicada a uma nica aplicao ou a um
contexto mais amplo, como um conjunto de aplicaes que
servem a determinadas reas de processo de negcio. A noo
da arquitetura permeia uma viso lgica, e independente de
tecnologia ou nveis de desenvolvimento. A criao desta
lgica permite entender o quanto um sistema forte ou
fracamente acoplado, alm de apoiar o raciocnio sobre os
efeitos da modificao ou a substituio de um componente.
No seguinte trabalho realizamos um estudo de caso criando
uma especificao de arquitetura de componentes para um
sistema de gerenciamento de solicitaes diversas de
muncipes (solicitantes) direcionadas a um setor de um
determinado departamento em uma prefeitura, o sistema em
questo foi desenvolvido em plataforma WEB.
Na prxima seo falamos da melhor forma de usar a
Unified Modeling Language (UML) para representar esses
conceitos de componentes e artefatos de modelo.
V. APLICANDO UML
UML uma linguagem de modelagem projetada para ser
estendida. Ela fornece uma linguagem base de ampla aceitao,
embora a sua aplicao a diferentes contextos pode precisar
que estes conceitos base ou sejam interpretados de maneiras
diferentes, ou sejam estendidos para incluir a desejada
semntica.
A. Estendendo UML com esteretipos
UML tem um certo nmero de mecanismos de extenso,
mas provavelmente o mais til, pelo menos em teoria, o
esteretipo. Praticamente qualquer elemento UML pode ter um
esteretipo ligado a ele; o nome do esteretipo aparece
normalmente no elemento cercado por . Esteretipos so
uma forma de permitir que os usurios criem novos tipos de
elementos de modelagem UML. Sempre que voc define um
esteretipo, UML permite tambm definir um conjunto de
restries que devem ser atendidas por todos os elementos
marcados com esse esteretipo.
B. Preciso, Acurcia e Completeza
Object Constraint Language (OCL) (ou Linguagem para
Especificao de Restries em Objetos, em portugus) uma
linguagem textual para a criao de expresses lgicas. OCL
nos permite ser muito mais precisos, especialmente quando se

especifica o comportamento de um componente. Usar OCL

melhora a preciso, mas no implica nada sobre a completeza
de um modelo. Infelizmente, preciso no implica acurcia.
Voc pode especificar um componente de software nos
mnimos detalhes, mas ainda acabar com algo que no
consegue atender necessidade. No entanto, a preciso em
modelos til porque permite testar a acurcia. Modelos
precisos so muito bons em gerar condies de teste.
C. Tcnicas de Modelagem UML
Ns definimos um nmero de diagramas correspondentes
aos artefatos que apoiam as tcnicas de modelagem UML, e
estes so apresentados na Fig. 1.

De maneira geral, usamos diagramas de classes de vrias

formas para capturar os aspectos estruturais ou estticos dos
nossos modelos de especificao e os diagramas de interao
para capturar os aspectos comportamentais e dinmicos dos
modelos de especificao.
Vamos agora percorrer o contedo de cada um dos modelos
(o conceito do negcio, casos de uso, tipo de negcio,
especificao de interface, especificao de componentes,
arquitetura de componentes) e mostrar como podemos aplicar
UML nesse contexto
D. Business Concept Model (Modelo Conceitual de Negcio)
O Modelo Conceitual de Negcio um modelo conceitual.
O principal objetivo do diagrama do modelo conceitual de
negcio captar conceitos e identificar relacionamentos. Ns
usamos um diagrama de classes UML para represent-lo, mas
importante notar que se trata de um modelo independente de
software. Modelos conceituais de negcio tipicamente
capturam classes conceituais e suas associaes. A Fig. 2
mostra um exemplo de diagrama de modelo conceitual de
negcio.

Fig. 1 Diagramas de modelagem de componentes

Os diagramas possuem os mesmos nomes que os artefatos

que eles visualizam. O Business Concept Model Diagram
(Diagrama de Modelo de Conceito de Negcio, em portugus)
um diagrama de classes que descreve o modelo de conceito
de negcio. Um Interface Specification Diagram (Diagrama de
Especificao de Interface) mostra uma especificao de
interface. E assim continua, com o Business Type Model
Diagram (Diagrama de Modelo de Tipo de Negcio), os
Component Specification Diagrams (Diagramas de
Especificao de Componente) e o Component Architecture
Diagram (Diagrama de Arquitetura de Componente) cada um
representando seu(s) artefato(s) correspondente(s).
As nicas variaes da correspondncia de nomenclatura
natural so o Interface Responsibility Diagram (Diagrama de
Responsabilidade de Interface) e o Component Interaction
Diagram (Diagrama de Interao entre Componentes). O
Interface Responsibility Diagram um diagrama de classes
que representa o tipo de modelo de negcio aumentado com
interfaces de negcios e aplicando algumas regras para a
atribuio de responsabilidade pela informao a essas
interfaces. O Component Interaction Diagram um diagrama
de colaborao aplicado interao entre objetos componentes.
Ns usamos o diagrama de colaborao para a modelagem
de interao, o diagrama de caso de uso para modelagem de
casos de uso e o diagrama de pacotes para organizar as coisas.
Ns no usamos o diagrama de componentes ou o diagrama de
implantao, porque estamos focando em especificao, no
em implementao.

Fig. 2. Um simples Modelo Conceitual de Negcio

E. Use Case Model (Modelo de Caso de Uso)

Casos de uso, da forma como os usamos, so uma projeo
dos requisitos de um sistema. Os participantes de um caso de
uso so os atores e o sistema. Um ator uma entidade que
interage com o sistema, tipicamente uma pessoa que assume
um papel. possvel que um ator seja outro sistema. Em um
caso de uso os atores interagem com o sistema como um todo,
e no uma parte especfica do mesmo. O sistema visto como
uma caixa preta homognea que aceita estmulos de atores e
gera respostas.
O propsito de um caso de uso cumprir a meta imediata
de um ator, como a colocao de uma ordem ou a verificao
de um saldo de conta bancria. Ele inclui tudo o que pode ser
feito agora ou em breve pelo sistema para cumprir a meta.
Os casos de uso tambm podem ser estendidos por outros
casos de uso e incluir outros casos de uso, e esses outros sero
necessariamente de granularidade mais fina do que a sua base.
Em UML, o elemento base, as extenses, e as incluses so os
elementos do modelo do tipo caso de uso.
1) Use Case Diagrams (Diagramas de Casos de Uso)
Diagramas de caso de uso so teis para definir a estrutura
geral do caso de uso em um diagrama (ver Fig. 3), mas ainda

deixa o detalhe real do caso de uso a ser capturado em

descries textuais de casos de uso (ver Fig. 4).

Fig. 3. Diagrama de casos de uso simples

Fig. 4. Descrio textual de um caso de uso

2) Use Case Descriptions (Descries de Caso de Uso)

Uma descrio de caso de uso contm pelo menos
um nome e / ou nmero de identificao
o nome do ator que inicia
uma breve descrio do objetivo do caso de uso
uma nica sequncia numerada de passos que
descrevem o cenrio de sucesso principal
O primeiro passo deve indicar o estmulo que inicia o caso
de uso (ou seja, o que o ator inicial faz para indicar ao sistema
que ele quer essa meta atingida).
O cenrio de sucesso principal descreve o que acontece no
caso mais comum e quando nada d errado. Ele dividido em
um nmero de passos. O pressuposto que passos so
executados estritamente sequencialmente na ordem dada.
Cada passo do caso de uso funciona como um ponto de
extenso de caso de uso. o ponto de ancoragem a partir do
qual um relacionamento de extenso para um caso de uso de
extenso pode ser definido. Passos de casos de uso sempre so
escritos em linguagem natural.
3) Use Case Instances (Instncias de Caso de Uso)
Uma descrio de caso de uso um modelo para
comportamento que instanciado no ambiente de um sistema

implantado cada vez que um ator gera um estmulo. Uma

instncia de caso de uso pode obter sucesso ou falhar no
cumprimento da meta.
4) Incluses, Extenses e Variaes
Um caso de uso pode incluir outro nomeando-o em um
passo. Isto significa que quando uma instncia do caso de uso
atinge esse passo, ele chama o caso de uso includo e depois
passa para o prximo passo.
As extenses so um mecanismo para especificao
semiformal de alternativas ou adies ao cenrio de sucesso
principal. Cada extenso descrita separadamente, aps o
cenrio de sucesso principal. Uma extenso compreende o
seguinte:
O nmero do passo (ou seja, ponto de extenso) no
cenrio de sucesso principal em que a extenso se
aplica.
Uma condio que deve ser testada antes de cada
etapa. Se a condio for verdadeira a extenso
ativada; se falsa a extenso ignorada e o cenrio de
sucesso principal continua como de costume.
A sequncia numerada de passos que constituem a
extenso.
O ltimo passo de uma extenso pode assumir uma das
seguintes formas:
Falha - para indicar que o caso de uso encerrado
com o objetivo insatisfeito.
Encerramento - para indicar que o caso de uso
encerrado com o objetivo satisfeito.
Voltar ao passo N - para indicar o prximo passo a ser
realizado no cenrio de sucesso principal.
Se o ltimo passo da extenso no um destes, o cenrio de
sucesso principal continua com o seu passo seguinte normal.
s vezes, ns sabemos que haver algumas variaes
significativas no fluxo de um caso de uso, mas no quer
especificar todos eles agora como extenses. Assim, podemos
incluir no final da descrio do caso de uso de uma lista de
Variaes. A variao apenas uma nota de texto livre dizendo
que a variao pode ocorrer.
F. Business Type Model (Modelo de Tipo de Negcio)
O Modelo de Tipo de Negcio um modelo de
especificao. Ele modelado usando um diagrama de classes
UML, mas seu propsito muito diferente ao do modelo
conceitual. O modelo de tipo de negcio est preocupado em
modelar com preciso as informaes de negcios que sejam
relevantes para o escopo do sistema previsto. A Fig. 5 mostra
um exemplo de modelo de tipo de negcio.
1) Types (Tipos)
Para indicar que as classes no modelo de tipo de negcio
so de nvel de especificao, usamos o esteretipo type.
Note-se, porm, que em nossos modelos de tipo de negcio os
tipos no podem ter operaes, porque eles descrevem apenas
informao, no software, enquanto que o esteretipo type
permite operaes.
a) Atributos

Atributos devem ser tipificados, e o tipo deve ser um tipo

de dados. A visibilidade irrelevante em um modelo de
especificao, j que nada interno ou privado, por isso
melhor definir como "pblico".

Fig. 5. Um modelo de tipo de negcio simples

b) Associaes
Tal como acontece com os atributos, associaes devem ter
visibilidade pblica. Usa-se navegabilidade (setas em
associaes) para indicar a responsabilidade por manter
associaes entre interfaces.
c) Significado de Atributo e Associao
importante lembrar que os modelos de tipo so modelos
de especificao. Em um modelo de tipo de negcio, um
atributo ou associao descreve um conjunto de dados
relacionados com o tipo nomeado no retngulo. Coletivamente,
os atributos e associaes definem um conjunto de consultas
que pode ser aplicado a um tipo ao escrever restries de
especificao em OCL. Eles so um vocabulrio formal para se
referir informao.
d) Atributos parametrizados
Um atributo parametrizado aquele cujo valor depende dos
valores de seus parmetros. Por exemplo, o nmero de contato
de uma pessoa pode ser dependente do dia da semana. Ento ao
invs de ter um atributo
contactNumber: String
podemos definir
contactNumber(day: Day): String
J que nosso esteretipo type no tem operaes (estes
pertencem s interfaces), isto deixa as "operaes" de type
disponveis para uso como atributos parametrizados. Elas
devem ser definidas como funes, sempre tendo um valor de
retorno. Pode ser til marcar essas operaes como atributos
usando um esteretipo como att.
2) Tipos de Dados Estruturados
Ns usamos as classes UML novamente para definir tipos
de dados estruturados e usamos o esteretipo datatype para
estes. Esse esteretipo define certas restries: O tipo de dados
no pode ter associaes, ou operaes, e atributos tambm
devem ser tipificados como tipos de dados (simples ou
estruturados). Durante a especificao de interface tambm
permitimos que atributos sejam referncias a objetos
componentes (ou seja, sejam do tipo interface).
3) Tipo Interface
Ns usamos uma classe estereotipada para representar uma
interface no nvel de especificao; o esteretipo chamado de
interface type. Tambm adotamos a conveno de prefaciar
os nomes das interfaces com "I".

a) Significado de Atributo e Associao

Tal como para todos os tipos, os atributos e associaes de
uma interface so para propsito de especificao apenas.
Quando chegamos fase de especificao detalhada para
interfaces, definimos o seu conjunto de atributos e funes de
associao, e seus tipos, como o prprio Interface Information
Model (Modelo de Informao de Interface, em portugus).
b) interface UML
A UML inclui um elemento de modelagem predefinido
chamado Interface. Ele desenhado como uma classe com um
esteretipo interface. As interfaces UML tem foco na
implementao, no tm atributos ou associaes, e nossas
interfaces precisam ter os dois, porque temos um foco na
especificao. Uma maneira til de pensar sobre a relao entre
um tipo interface e uma interface UML considerar uma
interface UML como uma potencial realizao de um tipo
interface, no habitual sentido "implementao realiza
especificao". A Fig. 6 exemplifica esta relao.

Fig. 6. Tipo Interface e Interface

4) Invariantes
UML define uma invariante como um esteretipo de
restrio, que se aplica aos classificadores e seus
relacionamentos. Para nossos propsitos, uma invariante ,
portanto, uma restrio em um modelo de tipo, e muitas vezes
usamos essas restries em modelos de tipo de negcio.
Costumamos escrever invariantes utilizando a OCL.
Uma invariante como uma regra sobre as instncias,
assim, no nvel de especificao muitas das invariantes
especificadas correspondem a regras de negcio.
G. Especificao de Interface
Uma especificao de interface uma interface em
conjunto com todos os outros apetrechos de especificao
necessrios para definir com preciso o que um componente
que oferece essa interface deve fazer, e o que um cliente dessa
interface pode esperar.
Uma especificao de interface consiste das seguintes
partes:
prprio tipo interface

Seu modelo de informao - os atributos e funes de

associao da interface, e seus tipos, transitivamente
at ao encerramento
Suas especificaes de operao - assinaturas de
operao e pr e ps-condies
Todas as invariantes adicionais sobre o modelo de
informao
1) Pacote de Especificao de Interface
Agrupamos todas essas informaes de especificao em
um nico pacote ento cada especificao de interface tem
seu prprio pacote. Este pacote pode importar informaes de
especificao de outros pacotes. Se estiver usando herana de
interface, possvel manter a estrutura de empacotamento e
propriedade exclusiva de tipo por meio da importao do
pacote do supertipo dentro do pacote do subtipo. A Fig. 7
mostra um exemplo de Pacote de Especificao de Interface.

Fig. 7. Pacote de Especificao de Interface

2) Modelo de Informao
Um dos objetivos da modelagem de componentes definir
especificaes de interfaces relativamente independentes. Ao
especificar interfaces buscamos definir uma srie de modelos
de tipo independentes, uma para cada interface. Cada interface
tem sua prpria viso das informaes que necessita. Por esta
razo, ns chamamos esses tipos de Tipos de Informao, para
distingui-los dos tipos de negcios no modelo de tipo de
negcio, e ns damos-lhes o esteretipo info type.
Ns descrevemos o modelo de informao de uma interface
em um diagrama de especificao de interface. Ele mostra
todos os tipos no modelo de informao e um diagrama
fundamental durante as tarefas detalhadas de especificao de
operao. Assim, o modelo de tipo de negcio consiste de tipos
de negcios (e interfaces), ao passo que um modelo de
informao interface consiste em uma interface e um conjunto
exclusivo de tipos de informao.
3) Especificao da operao
Uma especificao de operao consiste em uma assinatura
e um par de pr e ps-condio.

a) Assinatura
Uma operao definida em uma interface tem uma
assinatura que inclui zero ou mais parmetros tipificados. O
tipo de um parmetro pode ser:
uma referncia a um objeto componente; o tipo do
parmetro ser tipicamente uma interface
um tipo de dados simples
um tipo de dados estruturado
uma coleo de qualquer um destes
b) Par Pr e Ps-condio
Em UML, pr e ps-condies da operao so definidas
como restries nessa operao, com os esteretipos
precondition e postcondition, respectivamente. So
expresses booleanas normalmente escritas em OCL. A ideia
que, se a pr-condio for verdadeira, a ps-condio tambm
deve ser verdadeira. Se a pr-condio for falsa, o
comportamento indefinido.
c) Comportamento Transacional
Um tpico importante na especificao de operaes de
sistemas de componentes distribudos o seu comportamento
transacional, mas isso no coberto em UML. Em sistemas de
informao empresariais praticamente tudo transacional. Por
conseguinte, a questo de especificao resume-se a se uma
operao inicia sua prpria transao ou executada em uma
transao existente. Uma vez que esta uma escolha binria,
podemos model-la simplesmente atravs da definio de um
esteretipo de operao para um dos casos. Ns escolhemos o
caso de iniciar uma transao nova e definimos um esteretipo
transaction para ele.
H. Especificao de Componente
Ns definimos uma especificao de componente como
outro esteretipo de classe, chamado comp spec. Assim
como a distino entre uma interface UML e uma classe
interface type, um componente UML realiza uma classe
comp spec.
Uma especificao de componente oferece um conjunto de
tipos de interface. Ao nvel de implementao essa relao
"ofertas" modelada como uma realizao de um conjunto de
interfaces de um componente. Ns, portanto, definimos um
novo esteretipo de dependncia UML chamado offers para
capturar essa relao importante.
A especificao de componente o bloco de construo de
uma arquitetura de componentes. Alm do conjunto de
interfaces que ele oferece, ela define o conjunto de interfaces
que ele deve usar. Esta uma restrio de arquitetura, no uma
escolha de design de componentes. Modelamos isso com uma
dependncia de uso UML simples. Uma dependncia de uso
entre uma especificao de componente e um tipo de interface
especifica que todas as realizaes do componente devem usar
essa interface.
Uma especificao de componente tambm define
quaisquer restries que ele necessita entre essas interfaces e
quaisquer restries sobre a execuo de suas operaes. Essas
restries de implementao de operao podem ser definidas
usando interaes de componentes.

1) Interao entre Objetos Componentes

Usamos diagramas de colaborao UML para especificar as
interaes desejadas entre os objetos componentes. Estes
diagramas de interao de componente podem se concentrar
em um determinado objeto componente e mostrar como ele usa
as interfaces de outros objetos componentes. Ou eles podem
ser utilizados para descrever um conjunto de objetos
componentes interagindo numa arquitetura completa.
Os retngulos nos diagramas representam objetos
componentes que suportam as interfaces mostradas.
As ligaes devem ser instncias de associaes entre
interfaces que so parte da especificao de interface ou
especificao de componente, a menos que eles sejam
transitrios (ou seja, eles no existem mais do que a durao da
colaborao).
Na UML, as regras de nomeao para funes em uma
colaborao so nome do objeto/papel: nome do classificador.
Estamos usando instncias annimas por isso nossos nomes de
objetos esto em branco. Para os papis dos objetos usamos os
nomes de interface diretamente (a ideia considerar uma
interface como o papel de um objeto componente em uma
interao), e para o nome do classificador identificamos a
especificao de componente que oferece essa interface.
Em um diagrama de interao, apenas os objetos
componentes para os quais identificamos a especificao de
componente podem enviar mensagens, porque o envio de
mensagem uma funo do componente, no uma interface.
Cada diagrama de interao deveria mostrar, como uma
seta de entrada para um dos retngulos, o estmulo que causa a
interao.

entender como os componentes iro trabalhar juntos e

descobrir as operaes que so necessrias.
VI. DEFINIO DE REQUISITOS
Neste estudo iremos nos limitar a discutir como criar os
artefatos mnimos necessrios como entrada no fluxo de
trabalho de especificao. A ideia ter clareza sobre o
propsito e objetivo do software antes de comear a construlo.
A. Processos de Negcios
O diagrama de atividade UML que aparece na Fig. 9
demonstra o processo de registro de solicitaes no gabinete do
prefeito. O exemplo em questo ser utilizado como base para
o estudo de caso. No incio do processo solicitado o
Comprovante de Pessoa Fsica (CPF) ao solicitante. Caso o
CPF seja fornecido realizada uma busca pelo CPF, caso
contrrio, realizada uma busca pelo nome do solicitante no
cadastro. Nos casos que seja a primeira solicitao do cidado
este ser cadastrado no sistema. Estando o solicitante
previamente cadastrado registrada a solicitao e
posteriormente encaminhada para um setor da Prefeitura.

I. Arquiteturas de Componentes
A arquitetura de componentes define um contexto no qual
as dependncias de uso da interface de especificaes de
componentes autnomos esto vinculados s dependncias
offers de outras especificaes de componente autnomos.
Assim, em vez de uma srie de especificaes de
componentes independentes, temos uma nica arquitetura de
componentes. Chamamos o tipo de diagrama mostrado na Fig.
8 de Diagrama de Arquitetura de Componentes. Este mostra
uma arquitetura de especificao de componente (podemos
dizer que a partir dos esteretipos comp spec). A mesma
forma (usando a notao padro UML de sublinhado para
instncias) pode ser usada para mostrar uma arquitetura objeto
componente.
Fig. 9. Diagrama de Atividade do Processo de Registro de Solicitaes

Fig. 8. Uma Arquitetura de Especificao de Componente

Tambm desenhamos diagramas de interao de

componentes dentro de um contexto arquitetnico, para

B. Modelo Conceitual de Negcio

A descrio dos processos de negcio introduz um conjunto
de termos, tais como Solicitao, Assunto, Ttulo e Setor. Uma
ideia que ajuda na construo de um modelo conceitual de
negcio a utilizao de um mapa mental como ferramenta de
apoio, e podemos represent-lo na forma de um diagrama de
classes UML, como pode ser observado na Fig. 10. Deve ser
salientado que o modelo no est relacionado propriamente ao

software. O modelo de negcios uma das duas entradas

necessrias para o fluxo de trabalho de especificao.
O modelo conceitual de negcio no tem de ser bem
delimitado para o problema. A completude das vises
advinda do fluxo de trabalho de especificao. Outro aspecto
tambm se deve ao fato do modelo em questo no ser
completamente detalhado, ou seja, no vislumbrado, ainda,
os atributos, porm podem ser vistos de acordo com o
desenvolvimento do modelo.
At o momento no se tem a descrio do que realmente
uma solicitao, ou qual a sua relevncia no contexto em que
est inserida. Para o modelo assumido que o nome
suficiente para entendimento do propsito de alguma coisa.
Para isso importante a descrio de designaes. Uma
designao uma associao entre um termo designado (como
solicitante) e uma regra de reconhecimento (para que voc
saiba que um solicitante quando voc v um). No entanto,
pelo fato de sua configurao e simplicidade possvel a
extrao de conhecimento a partir do modelo. A Fig. 10
apresenta nosso modelo conceitual de negcio inicial.

funcionalidade fornecida pelo caso de uso) escrita.

medida que a anlise progride, os passos so preenchidos a fim
de se adicionar mais detalhes. Finalmente, os fluxos de exceo
so adicionados ao caso de uso. Os casos de uso identificados
esto no diagrama de casos de uso que aparece na Fig. 11.

Fig. 11. Diagrama de Casos de Uso Inicial

2) Descries de Casos de Uso
Nesta subseo esto includas as descries textuais dos
casos de uso do sistema.

Fig. 10. Modelo Conceitual de Negcio

C. Casos de Uso
Um modelo de caso de uso descreve como diferentes tipos
de atores interagem com o sistema para resolver um
determinado problema. No trabalho sero considerados os
atores: Solicitante(cidado) e Atendente. Com isso, o modelo
descreve as metas a serem atingidas, as interaes entre os
usurios e o Sistema de Solicitao, bem como o
comportamento necessrio do sistema para satisfazer estas
metas.
1) Identificao de Casos de Uso
A Especificao de Caso de Uso criada tipicamente na
Fase de Elaborao numa maneira iterativa. Inicialmente,
somente uma breve descrio dos passos necessrios para
executar o fluxo normal do caso de uso (isto , que

Fig. 12. Nova verso do Diagrama de Casos de Uso

VII. IDENTIFICAO DE COMPONENTES

Em um primeiro momento, a ao de encaminhar a
solicitao foi includa como um passo do caso de uso Gerar
Solicitao. Porm, ao realizar um refinamento foi verificado
que para permitir o seu reuso a ao de encaminhar a
solicitao deveria estar em um caso de uso separado. Abaixo
est a 2 verso do caso de uso Gerar Solicitao, onde este
inclui o caso de uso Encaminhar Solicitao no passo 17.

A identificao dos componentes, ilustrada na Fig. 13, o

primeiro estgio do fluxo de trabalho de especificao, que tem
como entradas o modelo conceitual de negcio e o modelo de
caso de uso. O objetivo da identificao dos componentes
criar um conjunto inicial de especificaes de interfaces e
componentes, ligados entre si formando uma arquitetura de
componentes.

Fig. 13. O estgio da identificao de componentes no fluxo de trabalho de

especificao

Sendo assim o nosso diagrama de casos de uso tambm teve

que ser atualizado, como mostra a Fig. 12.

O sistema separado em duas camadas distintas: Camada

de Servio de Sistema e a Camada de Servios de Negcios. A
separao permeia o fluxo de trabalho de especificao. Os
sistemas de interface e componentes so especificados na
camada de servios do sistema enquanto que as interfaces de
negcio e componentes do tipo de negcio so especificados na
camada de servios de negcios.
Os sistemas de interfaces emergem das consideraes do
modelo de caso de uso. embasado e derivado do sistema de
interaes.
A. Identificando Interfaces
Este estudo mais focado no sistema de negcio, que o
aspecto independente de interface de usurio de uma aplicao.

Considere as camadas da arquitetura de aplicao na Fig. 14;

ns caracterizamos a camada de dilogo com o usurio como
correspondendo ao software de dilogo com o usurio, que
atua como o iniciador de operaes em nossas interfaces do
sistema. O software de dilogo com o usurio implementa
lgica dos casos de uso, que so quebrados em passos (steps)
que so usados para identificar as operaes necessrias para
cumprir as responsabilidades do sistema.
Assim, as interfaces do sistema e suas operaes iniciais
surgem a partir de uma considerao do modelo de caso de
uso. As interfaces do sistema esto focadas em, e so derivadas
de, interaes do sistema.

Fig. 15. Os casos de uso so mapeados para interfaces de sistema

Fig. 14. Entradas de interface e correspondncia s camadas da arquitetura da
aplicao

O modelo conceitual de negcio auxilia o processo de

visualizar a informao e processos associados que o sistema
ter que gerenciar. Ns refinamos o modelo conceitual de
negcio, que representa uma viso humana do mundo, em um
modelo de tipo de negcio que representa a viso do sistema do
mundo, e, em seguida, o usamos para desenvolver um conjunto
de interfaces de negcio. As implementaes de componentes
suportando essas interfaces formam a lgica de negcio.
B. Identificando Interfaces do Sistema e Operaes
Numa primeira abordagem definido um tipo dilogo e
uma interface de sistema por caso de uso, como mostrado na
Fig. 15. Cada caso de uso serve para considerao da
modelagem das responsabilidades do sistema. A tarefa
representada como uma ou mais operaes para a interface de
sistema apropriada, possibilitando assim obter um conjunto
inicial de interfaces e operaes.
1) Gerar Solicitao
Para nosso caso de uso definimos uma interface do sistema
chamada IGerarSolicitao. No cenrio observado como
gerada a solicitao do Solicitante (cidado), bem como as
informaes importantes que devem ser avaliadas e vistas com
mais clareza. Sendo assim, as operaes importantes so
getDadosSolicitante() que retorna os dados importantes de
registro do cidado ao ser gerada uma solicitao;
getDadosSolicitao() que corresponde aos elementos
essenciais a uma Solicitao; e FazerSolicitao().
A ideia da extenso do caso de uso descrever um
comportamento alternativo sobre determinadas situaes.

2) Encaminhar Solicitao
A prxima interface do sistema que definimos a
IEncaminharSolicitao. No caso de uso Encaminhar
Solicitao realizado o envio da solicitao ao setor
correspondente para sua avaliao e futuro atendimento. Ao ser
enviada a solicitao o cidado receber uma notificao via email ou sms. As duas interfaces definidas at agora aparecem
na Fig. 16. At o momento elas no possuem parmetros
definidos para suas operaes. Deve ser visto que as interfaces
definidas se encontram na camada de servios do sistema, e
que so especficas para este sistema, ou seja, no so
tipicamente reutilizveis (embora sero bastante usadas nas
aplicaes requisitadas com o mesmo sistema subjacente). O
reuso de interfaces um dos propsitos das interfaces de
negcio.

Fig. 16. Interfaces IGerarSolicitacao e IEncaminharSolicitacao

C. Definindo as Interfaces de Negcio

As interfaces de Negcio so abstraes das informaes
que precisam ser gerenciadas pelo sistema. O processo de
identificao dado em 5 passos, so eles:
1. Produzir uma cpia do modelo conceitual de negcio e
alter-lo para o modelo de tipo de negcio.
2. Refinar o modelo de tipo de negcio e especificar
quaisquer regras de negcios e restries adicionais.
3. Identificar Core Business Types (Tipos-ncleo de
Negcio, em portugus)
4. Desenvolver interfaces de negcios para os tiposncleo e adicion-los ao modelo de tipo de negcio.
5. Refinar o modelo de tipo de negcio para indicar as
responsabilidades das interfaces de negcios.
1) Criando o Modelo de Tipo de Negcio

O primeiro passo na identificao dos tipos de negcio

converter o modelo conceitual de negcio produzido pelo fluxo
de trabalho de requisitos em um modelo de tipo de negcio.
Ns decidimos manter o modelo conceitual de negcio e no
edit-lo diretamente, pois ele representa um papel importante
na comunicao e entendimento dos envolvidos nos processos
de negcios. O modelo de tipo de negcio contm as
informaes de negcio especficas que precisam ser mantidas
pelo sistema que est sendo especificado.
Um tipo de negcio define dados/estado que a organizao
precisa manter e monitorar. Pode se tratar de um artefato fsico,
como um produto, ou abstrato, como um pedido.
2) Refinando o Modelo de Tipo de Negcio
O modelo de tipo de negcio inicialmente criado
copiando o modelo conceitual e adicionando ou removendo
elementos at que seu escopo esteja correto.
Verificamos quais os elementos que no agregam
informao til ao modelo. No exemplo, com intuito de
aumentar abstrao e simplificar o modelo a generalizao
Pessoa foi retirada e Departamento assume a funo de maior
grau na hierarquia, englobando Setor e Unidade. Com isso o
modelo se torna mais simples e conciso. Veja a Fig. 17.

Fig. 18. Modelo de tipo de negcio inicial

3) Definindo as Regras de Negcio

Ao identificar as regras de negcio possvel colocar as
restries associadas. No modelo que aparece na Fig. 19.
colocamos como exemplo algumas restries a serem
respeitadas. Se apresentam no formato UML colocado entre
chaves ({}) e possuem seu corpo definidos em OCL.

Fig. 19. Modelo de tipo de negcio

Fig. 17. Definindo o escopo do modelo de tipo de negcio

Em seguida, refinamos ainda mais o modelo atravs do

preenchimento de todos os detalhes que foram omitidos no
nvel conceitual, em particular, os detalhes dos atributos de
cada tipo, definindo um conjunto de tipos de dados para uso
neste modelo, e definindo restries do modelo, tais como
multiplicidades de associao. Nosso modelo de tipo de
negcio inicial aparece na Fig. 18.

4) Identificando Tipos-ncleo
Nessa fase decidimos quais tipos do modelo de tipo de
negcio ns consideramos como tipos-ncleo. O propsito de
identificar os tipos-ncleo comear a pensar e a trabalhar nas
informaes que so dependentes ou no de outras
informaes, podendo ou no atuarem sozinhas. Este um
passo importante em direo a alocao de responsabilidades
s interfaces. O tipo-ncleo de negcio dado como um tipo
de negcio que tem existncia independente dentro do negcio.
Os tipos-ncleo so indicados no modelo atravs do esteretipo
<<core>>. O esteretipo <<core>> absorve a semntica do
esteretipo <<type>>.

pkg

5) Criando Interfaces de Negcios e Atribuindo

Responsabilidades
A regra geral que uma interface de negcios seja criada
para cada tipo-ncleo no modelo de tipo de negcio. Cada
interface de negcios gerencia a informao representada pelo
tipo-ncleo e os tipos de detalhamento.
Criamos uma interface de gerenciamento chamada
lSolicitanteMgt, dos quais haver poucos casos (provavelmente
apenas um), e ao solicitante torna-se uma estrutura de dados
dentro dessa interface. Um nico objeto componente com
suporte ISolicitanteMgt ento gerencia muitos clientes.
Observa-se que cada tipo relacionado a apenas uma
inteface. A alocao dos tipos s interfaces demonstrada por
uma associao de composio. A Fig. 20 apresenta o
Diagrama de Responsabilidade de Interface do Modelo de Tipo
de Negcio.

Fig. 20. Diagrama de Responsabilidade de Interface do Modelo de Tipo de

Negcio

6) Alocando Responsabilidades para as Associaes

A associao entre Solicitante e Solicitao dita como
uma associao inter-interface, pois existe entre tipos
gerenciados por diferentes interfaces. Com isso preciso saber
quem guardar as informaes e como garantir a integridade
referencial.
Para reduzir a dependncia, queremos evitar sempre que
possvel, as referncias de duas vias entre as interfaces, por
isso, atribumos um caminho de navegabilidade de 1 via para
todas as associaes inter-interface. Assim, apenas uma
interface guardar as referncias. No trabalho, foi adotado que
Solicitao referencia Solicitante e Solicitante independente
de Solicitao. Significa que ISolicitanteMgt responsvel por
armazenar a referncia de Solicitante. Veja a Fig. 21.

ISolicitanteMgt

IDepartamentoMgt

Solicitante

Solicitao

Fig. 21. Atribuindo Direo de Rreferncia

D. Criando Especificaes de Interface Iniciais

O sistema de interfaces criados anteriormente, bem como
suas operaes, no so parte do modelo de tipos negcios, no
entanto formam um conjunto de especificaes de interfaces
iniciais, as quais sero refinadas.
Outro ponto que os sistemas de interfaces so
identificados e derivados dos casos de uso. Agora com o
conjunto de resultados obtidos os conjuntos de especificaes
possvel entender de maneira mais simplificada como as
partes se correlacionam.
E. Arquitetura de Especificao de Componentes
Um componente a unidade de implantao e reposio
em um sistema de componentes. No entanto, componentes
devem ser especificados de forma que as unidades de reposio
sejam as que desejamos e possam ser gerenciadas. Nesse
estgio existe um nmero de entradas potenciais para esta
atividade:

As interfaces no modelo de interface

Especificaes de componentes existentes a serem

reutilizados

Uma arquitetura de especificao de componente

existente quer queremos adaptar

Uma escolha de padro de arquitetura de

especificao de componentes
1) Especificao de Componentes de Negcio
Para as interfaces de negcio o ponto de partida uma
especificao de componentes por interface. No entanto, os
controladores/gerenciadores de interfaces so criados para
gerenciar instncias de tipos-ncleo de negcio, tipos de
negcio e detalhes associados. A Fig. 22 representa a
especificao de componente de sistema. As interfaces
ISolicitanteMgt e IDepartamentoMgt levam a especificaes
de componentes separadas como mostra a Fig. 23.

cmp

VIII. INTERAO DE COMPONENTES

<<comp spec>>
Sistema de Solicitao

IGerarSolicitao
IEncaminharSolicitao

<<comp
spec>>
Agora vamos decidir
como
os componentes iro trabalhar
Sistema
de
Solicitao
em conjunto para fornecer a funcionalidade IGerarSolicitao
necessria.
Chamamos esta segunda etapa do fluxo de trabalho de
especificao, ilustrada na Fig. 25, de Interao de
IEncaminharSolicitao
Componentes.

ISolicitanteMgt IDepartamentoMgt

ISolicitanteMgt IDepartamentoMgt

Fig. 22. Especificao de componente de sistema

<<comp spec>>
SolicitanteMgr

<<comp spec>>
DepartamentoMgr

Fig. 25. A etapa de interao de componentes do fluxo de trabalho de

especificao
Fig. 23. Especificaes de componentes de negcio

No
seguinte
trabalho
IGerarSolicitao
e
IEncaminharSolicitao fazem parte de uma especificao de
componente.
2) Uma Arquitetura Inicial
O resultado at ento obtido um conjunto inicial de
especificaes de componentes, que inclui as interfaces e as
suas dependncias. Uma vez que no temos qualquer interface
sendo oferecida por mais de uma especificao de componente
no nosso exemplo, podemos ligar as dependncias de interface
das especificaes de componentes diretamente com as suas
interfaces de especificao de componente correspondentes. A
arquitetura de especificao de componentes resultante aparece
na Fig. 24.
<<comp spec>>
Sistema de Solicitao

itao

IGerarSolicitao
IEncaminharSolicitao

Modelagem de interao uma tcnica de modelagem

comportamental genrica. Vamos utiliz-la aqui para definir as
diversas interaes que precisam ocorrer dentro do sistema,
para refinar as definies de interface j existentes, para
identificar como as interfaces sero utilizadas, e para descobrir
novas interfaces e operaes.
Nossos diagramas de colaborao mostram objetos
componentes que suportam as interfaces especficas. Cada
caixa como uma instncia de uma interface.
Estamos definindo as restries de implementao as
regras que devem ser mantidas para todas as implementaes
destes componentes.
A. Descobrindo Operaes de Negcios
Ns identificamos operaes necessrias em duas interfaces
do sistema:
IGerarSolicitacao
getDetalhesDepartamento()
gerarSolicitacao()
IEncaminharSolicitacao
getSolicitacao()
encaminharSolicitacao()

ISolicitanteMgt IDepartamentoMgt

<<comp spec>>
SolicitanteMgr

<<comp spec>>
DepartamentoMgr

Fig. 24. Arquitetura de especificao de componentes inicial

No sabemos as assinaturas destas operaes neste

momento, nem como elas sero implementadas usando os
componentes de negcios.
importante ter em mente que estamos tentando produzir
uma especificao, no um projeto de implementao, e temos
de ter cuidado para evitar especificao em excesso. Nosso
diagrama de arquitetura de componentes j diz aos
implementadores do Sistema de Solicitao que eles devem
usar as interfaces ISolicitanteMgt e lDepartamentoMgt.

Para descobrir as operaes de interface de negcios

tomamos cada operao de interface de sistema e desenhamos
um ou mais diagramas de colaborao que traam quaisquer
restries sobre os fluxos de execuo resultantes de uma
invocao dessa operao. Cada diagrama de colaborao deve
mostrar uma ou mais interaes, onde cada interao mostra
um possvel fluxo de execuo.
1) Algumas interaes Simples
getDetalhesDepartamento()
Sabemos a partir do caso de uso que o propsito de
getDetalhesDepartamento() fornecer uma lista de
departamentos a partir do qual o usurio possa escolher. O
usurio deve fornecer uma string para ser usada como uma
correspondncia parcial com os nomes de departamento;
apenas detalhes de departamentos com nomes correspondentes
sero devolvidos.
Ns decidimos que ela deveria retornar um
identificador nico de departamento para cada departamento.
Portanto, h um pouco de informao para retornar para
cada correspondncia de departamento e a operao estar
retornando potencialmente muitos desses conjuntos de
informaes. Nestas circunstncias, melhor definir um tipo de
dados estruturado para armazenar as informaes de cada
departamento. Ns o chamamos de DetalhesDepartamento (ver
Fig. X). Vamos retornar uma coleo dessas estruturas.
Departamentold um novo tipo de dados escalar que
introduzimos
para
representar
identificadores
de
departamentos.
A assinatura desta operao se torna

Como mostrado na Fig. 26, decidimos que

IDepartamentoMgt tambm deve ter uma operao
getDetalhesDepartamento(), com a mesma assinatura.
Mostramos os argumentos da operao, o que til para
ver a forma como a informao passada ao redor e para a
escrita de quaisquer condies ou restries baseadas em seus
valores.
2) Quebrando dependncias
Agora hora de olhar para uma interao mais interessante.
gerarSolicitacao()
A operao gerarSolicitacao() deve criar a solicitao e
notificar o solicitante por e-mail. Comeamos definindo a
assinatura para a operao. A operao precisa conhecer a
solicitao necessria, por isso, fornecemos uma estrutura
DetalhesSolicitacao como parmetro. Ela tambm precisa de
saber sobre o solicitante, por isso, definimos um novo tipo de
dados estruturado para manter dados dos solicitantes (Fig. 27).
Se este um novo solicitante todos os atributos so
necessrios, mas se for um solicitante existente o CPF s
necessrio se o nome no nico, e o endereo de e-mail no
sempre necessrio porque j o temos (mas o solicitante pode
fornec-lo de qualquer maneira).

IGerarSolicitacao::getDetalhesDepartamento
(in busca: String): DetalhesDepartamento[]

Passamos como parmetro uma string para comparar com

nomes de departamentos, e retornamos uma coleo de
DetalhesDepartamento. Podemos agora refinar a nossa
definio da interface IGerarSolicitacao adicionando os
detalhes da operao de assinatura.
Em tempo de execuo, esta operao invocada pela
camada de dilogo em um objeto componente Sistema de
Solicitao. Esse objeto no capaz de satisfazer a operao
em si, porque os componentes do sistema no armazenam
dados de negcios, por isso deve usar um objeto componente
que oferece a interface IDepartamentoMgt. A interao
necessria mostrada na Fig. 26.

Fig. 26. getDetalhesDepartamento()

Fig. 27. Tipo de dados estruturado para detalhes do solicitante

Sabemos a partir do caso de uso que o sistema deve

retornar uma tag ou nmero de referncia da solicitao recmcriada. Ns usamos uma string para isso, para que possamos
lidar com referncias alfanumricas. A assinatura da operao
torna-se
IGerarSolicitacao::gerarSolicitacao (entrada
s:
DetalhesSolicitacao,
entrada
st:
DetalhesSolicitante, sada rs: String): Integer

Ns estamos usando o valor de retorno para indicar o

resultado da operao, da seguinte forma:
0 Sucesso.
1 Este no um solicitante existente e o sistema no foi
capaz de criar um novo registro, pois o CPF no foi fornecido.
2 Nenhum CPF foi fornecido e o nome corresponde a mais
de um solicitante.
Internamente (ou seja, dentro do sistema) ns nos referimos
a um solicitante usando um identificador de solicitante
(idSolicitante). Enquanto passamos identificadores de
departamentos para a camada de dilogo vamos manter
identificadores dos solicitantes apenas como um conceito
interno.

Precisamos de uma operao em ISolicitanteMgt para

procurar detalhes de um solicitante e retornar o seu
idSolicitante, ento inventamos uma:
ISolicitanteMgt::getCustomerMatching
(entrada stD: DetalhesSolicitante, sada
StId): Integer

id:

Aqui, os valores de retorno so:

0 Sucesso - um nico solicitante correspondeu a pesquisa e
seu identificador retornado.
1 Este no um solicitante existente.
2 Nenhum CPF foi fornecido e o nome corresponde a mais
de um solicitante.
O componente DepartamentoMgr e o componente
SolicitanteMgr so independentes um do outro. No podemos
simplesmente permitir que o componente Sistema de
Solicitao encaminhe a chamada a gerarSolicitacao() para o
DepartamentoMgr e deix-lo ir em frente, porque o
DepartamentoMgr ento teria que usar ISolicitanteMgt para
verificar os detalhes do solicitante. Em vez disso, o Sistema de
Solicitao vai ter que fazer isso.
A Fig. 28 mostra a interao resultante, para o caso onde
detalhes sobre o solicitante j esto no arquivo. O Sistema de
Solicitao encontra o identificador do solicitante, em seguida,
passa-o na chamada para IDepartamentoMgt de modo que ele
pode ser armazenado diante a referida solicitao. A referncia
de solicitao retornada passada de volta para a camada de
dilogo, uma vez que o solicitante tenha sido notificado. Ns
decidimos que a operao notificarSolicitante() ter como
parmetros o identificador do solicitante e uma string contendo
a mensagem que se deseja enviar.

Fig. 28. Interao gerarSolicitacaoa( ) (solicitantes existentes)

O que podemos ver emergir aqui uma compreenso mais

clara da responsabilidade de cada interface e componentes, e as
dependncias entre eles. IGerarSolicitacao delega solicitaes
para IDepartamentoMgt e gerencia a associao com o
solicitante. ISolicitanteMgt responsvel por manter o controle
de solicitantes e seus detalhes, e manuseio de notificaes ao
solicitante.
B. Manuteno de integridade referencial
1) Arquitetura de Objeto Componente
Precisamos dizer claramente que o Sistema de Solicitao
sempre usar os mesmos objetos componentes de negcios.
Podemos fazer isso usando um diagrama de especificao de

componente para o componente Sistema de Solicitao. Como

este um diagrama de classe UML, podemos definir a
associao entre a especificao de componentes e as interfaces
que ele usa (Fig. 29). Podemos, ento, definir restries de
multiplicidade nessas associaes. A Fig. 29 deixa claro que o
Sistema de Solicitao sempre usar os mesmos objetos para
gesto de departamento e gesto de solicitantes.

Fig. 29. Restries sobre a Arquitetura Objeto Componente

2) Controlando Referncias Intercomponentes

Como vimos no incio desta seo, o objeto componente
DepartamentoMgr mantm as identidades dos solicitantes
como parte das informaes da solicitao. Como podemos
garantir que essas identidades so sempre vlidas? O que
acontece se apagar um solicitante?
Em geral, h uma srie de opes para a atribuio de
responsabilidade para assegurar que as referncias
intercomponentes so vlidas. Estas tambm podem ser
utilizados em combinao.
1. Responsabilidade pode ser atribuda ao objeto
componente armazenando a referncia d-lhe total e
exclusiva responsabilidade. No nosso exemplo, isso significaria
ter certeza que todos os pedidos para excluir solicitantes so
enviados para o objeto componente DepartamentoMgr; seria
ento responsvel por passar o pedido ao seu objeto
componente SolicitanteMgr. Nenhum outro objeto componente
seria capaz de acessar esse objeto componente SolicitanteMgr.
2. Responsabilidade pode ser alocada para o objeto
componente que possui o alvo da referncia. Em nosso
exemplo, este seria SolicitanteMgr. Ele teria que ter um
mecanismo para saber quais outros componentes esto
mantendo as referncias a ele e notificando-os de forma
adequada.
3. Responsabilidade pode ser dada a um terceiro objeto
componente, geralmente mais acima na cadeia de chamada.
Isto significaria fazer o Sistema de Solicitao responsvel
pelas excluses dos solicitantes e faz-lo interagir com
SolicitanteMgr e DepartamentoMgr.
4. Permitir, e tolerar, que referncias se tornem
invlidas.
5. No permitir a excluso de informaes.
A opo 1 no se encaixa com as nossas dependncias
escolhidas, de modo que desconsideramos essa opo. Ns
decidimos que, em nosso sistema, vamos procurar garantir que
as referncias de solicitantes mantidas por DepartamentoMgr
sejam sempre vlidas. Isto exclui a opo 4. Vamos supor

tambm que sabemos pelos casos de uso que a opo 5 no

possvel. Isso deixa as opes 2 ou 3. A opo 3 a mais
simples. O pedido de excluso iria para o Sistema de
Solicitao e ele iria garantir que todas as solicitaes para o
solicitante seriam removidas.
Infelizmente, h um obstculo com a opo 3. Ela assume
que o objeto componente SolicitanteMgr exclusivo para
Sistema de Solicitao e no compartilhado com qualquer
outro sistema. Assume-se que a operao deletarSolicitante()
de ICustomerMgt no ser chamada a partir de qualquer lugar
exceto o Sistema de Solicitao.
Como objetivo geral, quando desenvolvemos sistemas de
componentes, ns estamos tentando reutilizar objetos
componentes entre os sistemas. Queremos compartilhar cdigo
e dados em conjunto, e no apenas cdigo. A criao de
conjuntos de informaes exclusivas em diferentes sistemas
reduzir a integrao do negcio.
No entanto, se no podemos assumir exclusivo acesso
para o objeto SolicitanteMgr devemos usar a opo 2. Isso vai
ser mais complicado, porque qualquer objeto componente
mantendo uma identidade de solicitante ter que notificar os
objetos componentes SolicitanteMgr, que vo ter que manter
uma lista desses dependentes e notific-los quando houver a
excluso de um solicitante. Este um padro de design bem
conhecido chamado Observer.
C. Completando o quadro
Trs novas interaes completam a cobertura dos casos de
uso que consideramos at agora.
Primeiro, precisamos examinar o que acontece se um novo
solicitante faz uma solicitao (veja a Fig. 30). Isto indica a
necessidade de uma operao em ISolicitanteMgt para criar um
solicitante.

Fig. 31. Interao getSolicitacao( )

D. Refinando as Interfaces
Durante a modelagem de interao, ns nos concentramos
principalmente na alocao de responsabilidade e descoberta
de operaes. recomendvel que o processo de descoberta
seja razoavelmente irrestrito em sua fase inicial. Depois
podemos trazer outros fatores para modificar as especificaes.
1) Fatorando Interfaces e operaes
Fatorar uma interface envolve particionar suas
responsabilidades entre duas ou mais interfaces. O objetivo
muito semelhante ao de subtipagem para separar o
comportamento geral do comportamento mais especializado.
Fatorar tambm se aplica s operaes no sentido de que
podemos buscar generalidade e no-redundncia em operaes
de interface se for o caso.
Grande parte da flexibilidade no projeto de sistemas
baseado em componentes vem do fato de que os componentes
podem oferecer mltiplas interfaces. Quando aparecem novos
requisitos, o suporte pode ser fornecido atravs da adio de
novas interfaces.
IX. ESPECIFICAO DE COMPONENTES

Fig. 30. Interao gerarSolicitacaoa( ) (novo solicitante)

Passando para o caso de uso Encaminhar Solicitao, a

operao getSolicitacao() precisa retornar detalhes sobre a
solicitao e o solicitante. So necessrias mais operaes em
lDepartamentoMgt e ISolicitanteMgt (ver Fig. 31). A operao
retorna um resultado falso se a solicitao no for encontrada.

Dois tipos de contratos so observados em sistemas de

componentes: contratos de utilizao e de realizao. O
contrato de utilizao definido por uma especificao de
interface, enquanto que o contrato de realizao definido por
uma especificao de componente. Em outras palavras, as
especificaes de interfaces esto contidas nas duas ideias de
contratos, j que as especificaes de componentes so
primariamente agrupamentos de interfaces. O estgio de
especificao de componentes dado pela Fig. 32.

exigido um conjunto de informaes indicadas pelo tipo de

dados DetalhesSolicitante.
Uma interface s pode ser associada com tipos informao,
e esses tipos no podem ser associados a interfaces fora do
modelo de informaes de interface. A Fig. 33, demonstra um
diagrama de especificao de interface para a interface
ISolicitanteMgt.

Fig. 32. A etapa de especificao de componente do fluxo de trabalho de

especificao

A. Especificando Interfaces
As interfaces constituem um conjunto de operaes. Cada
operao define algum servio ou funo que um componente
realizar para um cliente. Uma operao, no entanto, representa
um contrato com granularidade fina entre um cliente e o objeto
componente. A interface tida como uma unidade contratual
atmica, e em geral uma operao no prov um nvel
adequado de gerenciamento de dependncias. Nesse quesito
preciso algo que descreva um estado do objeto componente, j
que as operaes no tm aspectos estruturais para isso e sim
as interfaces. Em alguns casos preciso que uma interface seja
separada em duas para que possam ser melhores gerenciadas.
1) Especificao de operaes
Uma operao especifica uma ao individual que um
objeto componente realiza para um cliente. As especificaes
implicam em outras facetas, tais como os parmetros de
entrada que especificam a informao provida ou repassada
para o objeto; ou parmetros de sada que especificam a
informao atual/atualizada ou de retorno para o objeto.
Cada operao precisa especificar como as entradas, sadas,
e o estado do objeto componente so relacionados, e que efeito
chamar a operao tem nesse relacionamento.
2) Modelos de Referncia de Informao
preciso representar os estados dos objetos componentes
das quais as interfaces so dependentes. Ao fazer isso, cada
interface tem um modelo de informao de interface. Isso um
modelo de tipo, modelado no diagrama de especificao de
interface, dos possveis estados de um objeto componente aos
quais as operaes podem se referir.
O modelo de informao de interface desenvolvido de
maneira incremental de acordo com a criao das
especificaes de operao, adicionando os tipos, atributos e
associaes necessrias. Foram determinadas quatro operaes
para a interface ISolicitanteMgt. As operaes demonstram as
necessidades de um modelo de informao de interface para as
interfaces. Qualquer objeto que prov/requisita ISolicitanteMgt
detm informao sobre solicitantes. Para cada solicitante

Fig. 33. Diagrama de especificao de interface para a interface

ISolicitanteMgt

3) Pr- e Ps-condies
Cada operao possui uma pr e ps-condio. Essa regra
define o efeitos da operao sem prescrever um algoritmo ou
tipo de implementao. Atuam na especificao nos detalhes
do que ser realizado pelas operaes bem como garantias para
a sua realizao.
A pr-condio a condio sob a qual a operao garante
que a ps-condio ser verdadeira. Se a pr-condio falsa
quando a operao invocada, o resultado simplesmente no
especificado.
B. Um Processo Sistemtico
O modelo de informao de interfaces um produto
derivado do modelo de tipo de negcio. O modelo que
representa o diagrama de responsabilidade de interfaces
(baseado em composies). IDepartamentoMgt visa a relao
entre departamentos e o gerenciamento de Solicitantes.
IDepartamentoMgt
responsvel por armazenar o
relacionamento entre Solicitaes e Solicitantes. Com
utilizao da ideia do diagrama de responsabilidade possvel
descrever o modelo de informao de Interface para
IDepartamentoMgt. Vale salientar que no modelo que aparece
na Fig. 34, IDepartamentoMgt no se preocupa
necessariamente com os detalhes de Solicitante e sim apenas
com a identidade de Solicitante. O modelo em questo visto
de maneira completa. importante observar que o tipo
Solicitante se encontra no pacote de IDepartamentoMgt e no
pacote de ISolicitanteMgt, porm os dois tipos se encontram
separados e so distintos, embora possam ser rastreados pelo
tipo Soliciante no modelo de tipo de negcio.

Fig.

36.

Snapshot

do

"after"

do

diagrama

de

instncias

para

IDepartamento::gerarSolicitacao()
Fig. 34. Diagrama de especificao de interface para IDepartamentoMgt

Um jeito prtico de criar um modelo de informao de

interfaces para interfaces de negcios trabalhar com uma
cpia do modelo de tipos de negcio, e a partir desse modelo
comear a remover os tipos, associaes, e atributos
desnecessrios.
1) Snapshots
Novamente com as pr e ps-condies, tido como uma
boa prtica o desenho do antes e depois (before/ after) dos
diagrama das instncias, colocando em evidncia as mudanas
de estados ocorridas. Esse diagrama de instncias nomeado
como Snapshot, que baseado no modelo de informao de
interfaces. O primeiro modelo, que aparece na Fig. 35
representa o before do diagrama de instncia (pr-condio).
E o after (ps-condio) aparece na Fig. 36.

Com esses modelos podemos visualizar o ato de se gerar

uma solicitao, com os detalhes de solicitao, e o
identificador do solicitante. assumido, por exemplo, um id
para departamento (id=6), outro para solicitante (id=45). A
utilizao do modelo de informao de interface auxilia a
realizao do snapshot, tornando mais simples as possveis
mudanas de estado. Com esse artifcio possvel escrever as
pr e pos-condies para GerarSolicitao.
C. Especificando Interface de Sistema
Os autores abordam como sendo uma passagem sistemtica
a forma de passar do modelo de tipo de negcio para o modelo
de informao das interfaces de negcio, e que a existncia de
um modelo de informao de interface no implica que uma
implementao da interface deve armazenar as informaes
persistentemente., pelo contrrio, raramente acontece algum
armazenamento desse tipo. Suas implementaes obtm as
informaes que necessitam de componentes de negcios.
X. CONCLUSO
O trabalho demonstrou as tarefas necessrias para a
realizao de uma componentizao de um sistema. Foi
observado no se tratar de uma tarefa trivial e sim um tanto
complexa e custosa. Acreditamos que o objetivo foi cumprido,
uma vez que realizamos a especificao de componentes e
interfaces de um sistema real, aplicando os conceitos
aprendidos sobre o tema e obtendo mais conhecimento com a
prtica.

Fig.

35.

Snapshot

do

"before"

IDepartamento::gerarSolicitacao()

do

diagrama

de

instncias

para

REFERNCIAS
[1] J. Cheesman and J. Daniels, UML Components: A Simple
Process for Specifying Component-based Software. AddisonWesley, 2001.
[2] L. Bass, P. Clements, and R. Kazman, Software Architecture in
Practice. Pearson Education, 2012.
[3]