Unidade 4

Prévia do material em texto

PROJETO DE SISTEMAS 
 
 1. Introdução 
O projeto é o que virtualmente todo engenheiro quer fazer. É o 
lugar em que a criatividade impera – em que os requisitos do 
cliente, as necessidades de negócio e as considerações técnicas se 
juntam na formulação de um produto ou sistema. O projeto cria 
uma representação ou modelo do software, mas diferente do 
modelo de análise (que enfoca a descrição dos dados, função e 
comportamento requeridos), o modelo de projeto fornece detalhe 
sobre as estruturas de dados, arquitetura, interfaces e componentes 
do software necessários para implementar o sistema. 
O projeto engloba um conjunto de princípios, conceitos e 
práticas que levam ao desenvolvimento de um sistema ou produto 
de alta qualidade. Princípios de projeto estabelecem uma filosofia 
prevalecente que guia o projetista no trabalho realizado. Conceitos 
de projeto devem ser compreendidos antes que a “mecânica” do 
projeto seja aplicada, e práticas de projeto em si levam à criação 
de várias representações de software que norteiam a atividade de 
construção que se segue. 
A importância do projeto se deve ao fato de que permite ao 
engenheiro de software modelar o sistema ou produto que deve ser 
construído. Esse modelo pode ser avaliado quanto à qualidade e 
aperfeiçoamento antes que o código seja gerado, testes sejam 
conduzidos e usuários finais fiquem envolvidos em grande número. 
Na fase de projeto a qualidade de software é estabelecida. 
Os passos para o desenvolvimento do projeto são: primeiro, a 
arquitetura do sistema ou produto precisa ser representada. 
Depois, as interfaces que conectam o software aos usuários finais, 
a outros sistemas e dispositivos e aos seus próprios componentes 
constitutivos são modelados. Por fim, os componentes de software 
usados para construir o sistema são projetados. Cada uma dessas 
visões representa uma diferente ação do projeto, mas todas 
136
precisam estar de acordo com um conjunto de conceitos básicos de 
projeto que norteiam todo o trabalho de projeto de software. 
 
 
2. Conceitos de Projeto de Sistemas 
Um conjunto de conceitos fundamentais de projeto de software 
tem evoluído durante a história da engenharia de software. Apesar 
de o grau de interesse em cada conceito ter variado ao longo dos 
anos, cada um resistiu ao tempo, fornecendo ao projetista de 
software uma base por meio da qual métodos mais sofisticados de 
projeto podem ser aplicados. 
 
2.1 Abstração 
Quando consideramos uma solução modular para qualquer 
problema, muitos níveis de abstração podem ser colocados. No nível 
mais alto de abstração, uma solução é enunciada em termos 
amplos usando a linguagem do ambiente do problema. Nos níveis 
mais baixos de abstração, uma descrição mais detalhada da 
solução é fornecida. 
À medida que nos deslocamos entre diferentes níveis de 
abstração, trabalhamos para criar abstrações procedimentais e de 
dados. Uma abstração procedural refere-se a uma seqüência de 
instruções que tem uma função específica e limitada. O nome de 
uma abstração procedural implica essas funções, mas detalhes 
específicos são omitidos. A abstração de dados é uma coleção de 
dados com um denominação que descreve um objeto de dados. 
Como projetista, devemos trabalhar duro para deduzir tanto 
abstrações procedurais quanto de dados que sirvam ao problema, 
mas que também possam ser reutilizadas em outras situações. 
 
2.2 Arquitetura 
Em sua forma mais simples, arquitetura é a estrutura ou 
organização dos componentes de programa (módulos), o modo pelo 
137
qual esses componentes interagem e as estruturas dos dados que 
são usadas pelos componentes. Em um sentido mais amplo, no 
entanto, componentes podem ser generalizados para representar os 
principais elementos do sistema e suas interações. 
Uma meta do projeto de software é derivar um quadro 
arquitetural do sistema. Esse quadro serve como arcabouço com 
base no qual as atividades de projeto detalhado são conduzidas. 
Um conjunto de padrões de software arquiteturais permite ao 
engenheiro de software reusar conceitos de projeto. 
O projeto arquitetural pode ser representado usado um ou 
vários modelos diferentes. Modelos estruturais representam a 
arquitetura como uma coleção organizada de componentes de 
programa. Modelos de arcabouço aumentam o nível de abstração 
de projeto tentando identificar arcabouços de projeto arquitetural 
repetíveis (padrões), que são encontrados em tipos de aplicação 
similares. Modelos dinâmicos tratam dos aspectos comportamentais 
da arquitetura de programa, indicando como a estrutura ou a 
configuração do sistema pode mudar em função de eventos 
externos. Modelos de processo focalizam o projeto dos processos 
de negócio ou técnicos que o sistema deve acomodar. Por fim, 
modelos funcionais podem ser usados para representar a hierarquia 
funcional de um sistema. 
Não devemos deixar que a arquitetura apenas aconteça. Se o 
fizermos, vamos gastar tempo de projeto tentando encaixar nela o 
projeto à força. Devemos projetar a arquitetura de forma clara e 
objetiva. 
 
2.3 Padrões 
Um padrão de projeto descreve uma estrutura de projeto que 
resolve um problema particular de projeto em um contexto 
específico e em meio a “forças” que podem ter impacto na maneira 
pela qual o padrão é aplicado e usado. 
A intenção de cada padrão de projeto é fornecer uma descrição 
que habilite o projetista a determinar: a) se o padrão é aplicável ao 
trabalho corrente; b) se o padrão pode ser reutilizado 
(consequentemente, ganhando tempo de projeto) e; c) se o padrão 
138
pode servir como guia para desenvolvimento de um padrão similar, 
mas funcionalmente ou estruturalmente diferente dele. 
 
2.4 Modularidade 
Arquitetura de software e padrões de projetam incorporam 
modularidade; o software é dividido em componentes nomeados 
separadamente e endereçáveis, algumas vezes chamados de 
módulos, que são integrados para satisfazer aos requisitos do 
problema. 
Costuma-se dizer que a modularidade de um sistema define se 
ele é gerenciável intelectualmente. Softwares monolíticos (um 
programa grande composto de um único módulo) não pode ser 
facilmente compreendido por um engenheiro de software. O número 
de caminhos de controle, intervalos de referência, número de 
variáveis e a complexidade global faz com que a compreensão seja 
quase impossível. 
A complexidade perceptível de dois problemas, quando 
combinados, é em geral maior que a soma da complexidade 
perceptível quando cada problema é considerado separadamente. 
Isso leva à estratégia “dividir e conquistar” – é mais fácil 
resolvermos um problema complexo quando dividimos em partes 
gerenciáveis. Isso tem implicações importantes como relação à 
modularidade e ao software. É na realidade um argumento a favor 
da modularidade. 
É possível concluir que se subdividirmos o software 
indefinidamente, o esforço necessário para desenvolvê-lo 
tornar-se-á pequeno. Infelizmente, outras forças entram em jogo, 
fazendo com que essa conclusão seja tristemente inválida. 
Observando a Figura 4.1, o esforço (custo) para desenvolver um 
módulo de software individual de fato diminui à medidaque o 
número total de módulos aumenta. Dado o mesmo conjunto de 
requisitos, mais módulos significa menor tamanho individual. No 
entanto, à medida que o número de módulos cresce, o esforço 
(custo) associado à integração dos módulos também cresce. Essa 
característica leva à curva de custo, ou esforço total, mostrada na 
figura. Há um número M de módulos que resultaria no custo de 
139
desenvolvimento, mas não temos a sofisticação necessária para 
prever M com segurança. Dessa forma, não devemos modularizar 
demais um sistema. A simplicidade de cada módulo será 
comprometida pela complexidade da integração. 
 
Figura 4.1–Modularidade e custo de software (Fonte: Pressman, 2006). 
 
 
2.5 Ocultamento da Informação 
O conceito de modularidade leva todo projetista de software a 
uma questão fundamental: “Como decompomos uma solução de 
software para obter o melhor conjunto de módulos?”. Módulos 
devem ser especificados e projetados para que a informação 
(algoritmos e dados) contida em um módulo seja inacessível a 
outros módulos que não necessitam dessa informação. 
Ocultamento implica que efetiva modularidade pode ser 
conseguida pela definição de um conjunto de módulos 
independentes que informam uns aos outros apenas o necessário 
para realizar uma função de software. Abstração ajuda a definir as 
entidades procedurais (ou informacionais) que constituem o 
software. Ocultamento define e impõe restrições de acesso, tanto a 
detalhes de processamento dentro de um módulo quanto a qualquer 
estrutura de dados local usada pelo módulo. 
O uso de ocultamento da informação como critério de projeto 
para sistemas modulares fornece os maiores benefícios quando são 
necessárias modificações durante o teste e, posteriormente, 
140
durante a manutenção do software. Como a maior parte dos dados 
e procedimentos estão ocultas de outras partes do software, erros 
inadvertidamente introduzidos durante a modificação são menos 
prováveis de serem propagados para outros módulos do software. 
Além disso, o conhecimento de detalhes não precisa ser algo que os 
usuários do módulo devam saber. 
 
2.6 Independência Funcional 
A independência funcional é uma decorrência direta da 
modularidade e dos conceitos de abstração e ocultamento da 
informação. Ela é obtida pelo desenvolvimento de módulos com 
função de “finalidade única” e não recomenda a interação excessiva 
entre os módulos. Os módulos independentes são mais fáceis de 
desenvolver, de manter e de testar: a função pode ser 
compartimentalizada, as interfaces são simplificadas, os efeitos 
secundários causados por modificação de projeto ou código são 
limitados, a propagação de erros é reduzida e os módulos reusáveis 
são possíveis. 
A independência é avaliada por meio de dois critérios 
qualitativos: coesão e acoplamento. A coesão indica robustez 
funcional relativa a um módulo e é uma extensão natural do 
conceito de ocultamento da informação. Um módulo coeso realiza 
uma única tarefa, requerendo pouca interação com outros 
componentes em outras partes do programa. O acoplamento indica 
a interdependência relativa entre módulos e depende da 
complexidade da interface entre módulos, do ponto em que é feita a 
entrada ou referência a um módulo e de quais dados passam pela 
interface. Em projetos de software, o objetivo é conseguir o 
acoplamento mais baixo possível. 
 
2.7 Classes de Projeto 
Na Unidade 3, vimos que o nível de abstração de uma classe 
de análise é relativamente alto. À medida em que o modelo de 
projeto evolui, a equipe de desenvolvimento de software deve 
definir um conjunto de classes de projeto que refina as classes de 
análise, fornecendo detalhes de projeto que vão permitir que as 
141
classes sejam implementadas, e crie um conjunto de classes de 
projeto que implemente uma infra-estrutura de software para apoiar 
a solução do negócio. Cinco diferentes tipos de classes de projeto, 
cada um representando uma camada diferente do projeto de 
arquitetura, são sugeridos: 
● Classes de interface com o usuário: definem todas as 
abstrações necessárias para a interação entre homem e 
computador. 
● Classes do domínio de negócio: frequentemente são 
refinamentos de classes de análise definidas 
anteriormente. As classes identificam os atributos e 
métodos necessários para implementar algum elemento 
do domínio de negócio. 
● Classes de processo: implementam abstrações de mais 
baixo nível de negócio necessárias para a completa 
gestão das classes de domínio de negócios. 
● Classes persistentes: representam depósitos de dados 
que vão persistir além da execução do software. 
● Classes de sistema: implementam funções de gestão e 
controle de software que habilitam o sistema a operar e 
se comunicar em seu ambiente e com o mundo externo. 
 
2. Projeto no contexto da Engenharia de Software 
O projeto de software situa-se no núcleo técnico da 
engenharia de software e é aplicado independentemente do modelo 
de processo de software usado. Iniciando logo que os requisitos de 
software tenham sido analisados e modelados, o projeto de 
software é a última ação do engenheiro de software dentro da 
atividade de modelagem e prepara a cena para construção (geração 
de código e teste). 
Cada um dos elementos do modelo de análise fornece 
informação necessária para criar os quatro modelos necessários 
para uma completa especificação do projeto. O fluxo de informação 
durante o projeto de software é mostrado na Figura 4.2. O modelo 
de análise manifestado por elementos baseados em cenário e em 
classe, orientados a fluxo e comportamentais alimenta a tarefa de 
projeto. 
142
 
 
 Figura 4.2–Tradução do modelo de análise para um modelo de projeto (Fonte: 
Pressman, 2006). 
 
Durante o projeto tomamos decisões que vão, em ultima 
análise, afetar o sucesso da construção do software e, mais 
importante, a facilidade com a qual o software pode ser mantido. 
Mas por que o projeto é tão importante? 
A importância do projeto de software pode ser definida com 
uma única palavra – qualidade. Projeto é a etapa na qual a 
qualidade é incorporada na engenharia de software. O projeto nos 
fornece representações do software que podem ser avaliadas 
quanto à qualidade. É o único modo pelo qual podemos traduzir 
precisamente os requisitos do cliente em um produto ou sistema de 
software acabado. O projeto de software serve de base para todos 
os passos de engenharia de software e de suporte de software que 
se seguem. Sem projeto, nos arriscamos a construir um sistema 
instável – que falhará quando pequenas modificações forem feitas; 
143
que pode ser difícil de testar; cuja qualidade não pode ser avaliada 
até uma fase avançada do processo de software, na qual o prazo 
está se esgotando e muito dinheiro já foi gasto. 
No processo iterativo de um projeto de software, os requisitos 
são traduzidos em um “documento” para construção do software. 
Inicialmente o documento mostra uma visão holística do software, 
ou seja, o projeto é representado em um alto nível de abstração, 
nível que pode ser diretamente relacionado ao objetivo específico 
do sistema e arequisitos mais detalhados de dados, funcionais e 
comportamentais. À medida que ocorrem as iterações de projeto, os 
refinamentos subsequentes levam a representações de projeto em 
níveis de abstração muito mais baixos. Esses ainda podem ser 
relacionados aos requisitos, mas a conexão é mais sutil. 
Ao longo do processo, a qualidade do projeto em evolução é 
avaliada com uma série de revisões técnicas formais ou 
walkthroughs de projetos. Um bom projeto deve: 
● Implementar todos os requisitos explícitos contidos no 
modelo de análise e acomodar todos os requisitos 
implícitos desejados pelo cliente; 
● Ser um guia legível, compreensível para aqueles que 
geram código e para os que testam e, 
subsequentemente, dão suporte ao software; 
● Fornecer um quadro completo do software, focalizando 
os domínios de dados, funcional e comportamental sob 
uma perspectiva de implementação. 
 
Um modelo de projeto pode ser visto em duas dimensões 
diferentes como ilustrado na Figura 4.3. A dimensão processo indica 
a evolução do modelo de projeto à medida que as tarefas são 
executadas como parte do processo de software. A dimensão 
144
abstração representa o nível de detalhe à medida que cada 
elemento do modelo de análise é transformado em um projeto 
equivalente e, então, refinado iterativamente. Observando a figura, 
a linha pontilhada indica a fronteira entre os modelos de análise e 
projeto. Em outros casos, o modelo de análise paulatinamente se 
mistura ao modelo de projeto e uma distinção clara é menos óbvia. 
 
Figura 4.3–Dimensões do modelo de projeto (Fonte: Pressman, 2006). 
 
Os elementos do modelo de projeto usam muitos dos mesmos 
diagramas UML que foram usados no modelo de análise. A diferença 
é que esses diagramas são refinados e elaborados como parte do 
projeto; mais detalhe específico de implementação é fornecido e 
são enfatizadas a estrutura e o estilo arquitetural, os componentes 
que residem na arquitetura e as interfaces entre os componentes e 
o mundo externo. 
É importante mencionar, no entanto, que os elementos do 
modelo anotados ao longo do eixo horizontal não são sempre 
desenvolvidos de forma sequencial. Na maioria dos casos, o projeto 
de arquitetura preliminar prepara o palco e é seguido pelo projeto 
de interface e projeto em nível de componente, que frequentemente 
145
ocorrem em paralelo. O modelo de implantação é usualmente 
adiado até que o projeto tenha sido totalmente desenvolvido. 
 
 
3.1 Projeto de dados /classes 
O projeto de dados / classes transforma modelos de 
análise-classe em realizações de classes de projeto e nas 
estruturas de dados dos requisitos necessárias para implementar o 
software. As classes e os relacionamentos definidos nos cartões de 
índice CRC e o conteúdo detalhado dos dados mostrados pelos 
atributos das classes e outras notações fornecem a base para a 
atividade de projeto de dados. Parte do projeto de classes pode 
ocorrer em conjunção com o projeto da arquitetura do software. O 
projeto de classe mais detalhado ocorre à medida que cada 
componente do software é projetado. 
Como outras atividades de engenharia de software, o projeto 
de dados (algumas vezes denominado arquitetura de dados) cria um 
modelo de dados e/ou informação que é representado no nível mais 
alto de abstração (a visão dos dados do cliente / usuário). Esse 
modelo de dados é então refinado em representações cada vez mais 
específicas da implementação que podem ser processadas pelo 
sistema baseado em computador. Em muitas aplicações de 
software, a arquitetura dos dados terá uma profunda influência na 
arquitetura do software que deve processá-los. 
A estrutura de dados é uma parte importante do projeto de 
software. No nível de componente de programa, o projeto das 
estruturas de dados e dos algoritmos associados necessários para 
manipulá-las é essencial para a criação de aplicações de alta 
qualidade. No nível de aplicação, a tradução do modelo de dados 
(derivado como parte da engenharia de requisitos) para um banco 
146
de dados é fundamental para satisfazer aos objetivos de negócios 
de um sistema. Em nível de negócio, a coleção de informação 
armazenada em diferentes bancos de dados e reorganizada em um 
“armazém de dados” (data warehouse) possibilita a mineração de 
dados ou descoberta de conhecimento que pode ter impacto no 
sucesso do próprio negócio. Em qualquer caso, o projeto de dados 
desempenha um papel importante. 
 
3.2 Projeto arquitetural 
O projeto arquitetural define os relacionamentos entre os 
principais elementos estruturais do software, os estilos 
arquiteturais e padrões de projeto que podem ser usados para 
satisfazer aos requisitos definidos para o sistema e as restrições 
que afetam o modo pelo qual o modelo arquitetural pode ser 
implementado. A representação do projeto arquitetural – o 
arcabouço de um sistema baseado em computador – pode ser 
derivada da especificação do sistema, do modelo de análise e da 
interação dos subsistemas definida no modelo de análise. 
O projeto arquitetural do software é o equivalente à planta 
baixa de uma casa. A planta baixa representa a disposição global 
dos cômodos, seu tamanho, forma e relacionamento entre eles, e 
as portas e janelas que permitem movimento para dentro e para 
fora dos cômodos. A planta baixa nos dá uma visão geral da casa. 
Elementos do projeto arquitetural nos dão uma visão geral do 
software. 
Por constituírem um processo criativo em que se tenta 
estabelecer uma organização de sistema que satisfaça os requisitos 
funcionais e não funcionais do sistema, as atividades de processo 
do projeto arquitetural podem ser muito diferentes dependendo do 
tipo de sistema que será desenvolvido, da origem, da experiência 
147
do arquiteto do sistema e dos requisitos específicos do sistema. É, 
portanto, mais útil pensar no processo de projeto de arquitetura sob 
uma perspectiva de decisão em vez de uma perspectiva de 
atividade. 
O resultado do processo de projeto arquitetural é expresso em 
um documento de projeto arquitetural. Ele pode incluir várias 
representações gráficas do sistema junto com um texto descritivo 
associado. Deve ser descrito como o sistema está estruturado em 
subsistemas, a abordagem adotada e como cada subsistema está 
estruturado em módulos. Ao decorrer desta seção serão ilustradas 
algumas representações arquiteturais com foco na organização do 
sistema e outras direcionadas ao estilo arquitetural. 
 
3.2.1 Organização de sistema 
A organização de um sistema reflete a estratégia básica para 
estruturá-lo. Precisamos tomar decisões sobre o modelo geral 
organizacional de um sistema com antecedência no processo de 
projeto arquitetural. A organização do sistema pode refletir-se 
diretamente na estrutura do subsistema. Em muitos casos, mais de 
um estilo pode ser adequado e alternativas podem ser projetadas e 
avaliadas. Por exemplo, uma arquitetura em camadas (adequada à 
maioria dos sistemas) pode ser combinada com uma arquitetura de 
repositório (centrada em dados) emmuitas aplicações de banco de 
dados. 
Nesta seção abordaremos três estilos organizacionais 
amplamente usados que podem ser implementados separadamente 
ou juntos: o modelo de repositório, o modelo cliente-servidor e o 
modelo em camadas. 
 
3.2.1.1 Arquitetura de repositório (ou centrada nos dados) 
148
A maioria dos sistemas que usam grandes quantidades de 
dados é organizada com base em um banco de dados ou repositório 
compartilhado. Esse modelo é, portanto, adequado para aplicações 
em que dados são gerados por um subsistema e usados por outro. 
Exemplos desse tipo de sistema incluem sistemas de comando e 
controle, sistemas de informações gerenciais, sistemas CAD e 
ferramentas CASE. A Figura 4.4 ilustra um exemplo de uma 
arquitetura de conjunto de ferramentas CASE. 
 
 
Figura 4.4–Arquitetura de um conjunto de ferramentas CASE integradas 
(Fonte: Sommerville, 2007). 
 
 
3.2.1.2 Arquitetura cliente-servidor 
No modelo de arquitetura cliente-servidor o sistema é 
organizado como um conjunto de serviços, servidores e clientes 
associados que acessam e usam os serviços. Os principais 
componentes desse modelo são: 
● um conjunto de servidores que oferecem serviços para 
outros subsistemas; 
● um conjunto de clientes que solicita os serviços 
oferecidos pelos servidores e; 
● uma rede que permite aos clientes acessarem esses 
149
serviços. 
 
Os clientes talvez precisem saber os nomes dos servidores 
disponíveis e os serviços que eles fornecem. No entanto, os 
servidores não precisam saber a identidade dos clientes ou quantos 
clientes existem. Os clientes acessam os serviços fornecidos pelo 
servidor por meio de chamadas remotas de procedimento usando 
um protocolo request-reply, como o protocolo http utilizado na Web. 
Essencialmente, um cliente faz um pedido a um servidor e espera 
até receber uma resposta. A Figura 4.5 ilustra um exemplo de um 
sistema baseado no modelo ciente-servidor. 
 
Figura 4.5–Arquitetura de um sistema de acervo de filmes e fotografias (Fonte: 
Sommerville, 2007). 
 
3.2.1.3 Arquitetura em camadas 
A estrutura básica de uma arquitetura em camadas é ilustrada 
na Figura 4.6. Um certo número de camadas diferentes é definido, 
cada uma realizando operações que se tornam progressivamente 
mais próximas do conjunto de instruções da máquina. Na camada 
exterior, os componentes servem as operações da interface com o 
usuário. Na camada mais interna, os componentes realizam a 
interface com o sistema operacional. As camadas intermediárias 
150
fornecem serviços utilitários e funções do software de aplicação. 
 
 
Figura 4.6–Arquitetura em camadas (Fonte: Pressman, 2006). 
 
3.2.2 Estilos arquiteturais 
Depois de escolhida a organização geral do sistema, 
precisamos tomar uma decisão sobre o estilo arquitetural 
empregado na análise modular dos subsistemas. Não há uma 
distinção rígida entre organização do sistema e o estilo arquitetural 
empregado, pois as arquiteturas descritas anteriormente podem ser 
aplicadas neste nível. No entanto, achamos melhor descrevê-las 
separadamente para proporcionar melhor compreensão. 
Os estilos arquiteturais são apenas um pequeno subconjunto 
dos que estão disponíveis para o projetista de software. Depois que 
a engenharia de requisitos descobre as características e restrições 
do sistema a ser construído, o estilo arquitetural ou combinação de 
estilos, que melhor se encaixa nessas características e restrições, 
pode ser escolhido. Abordaremos a arquitetura de fluxo de dados e 
a arquitetura orientada a objetos. 
 
3.2.2.1 Arquitetura de fluxo de dados 
151
Na arquitetura de fluxo de dados (ou pipelining orientado a 
funções), as transformações funcionais processam suas entradas e 
produzem saídas. Os dados fluem de uma função a outra e são 
transformados ao moverem-se seqüencialmente. Cada etapa do 
processamento é implementada como uma transformação. Os dados 
de entrada fluem através dessas transformações até serem 
convertidos em saída. As transformações podem ser executadas 
seqüencial ou paralelamente. Os dados podem ser processados por 
cada transformação item por item ou em um único lote. 
Quando as transformações são representadas como processos 
separados, esse modelo é algumas vezes chamado estilo de duto 
(pipe) e filtro. Quando as transformações são seqüenciais com 
dados processados em lotes, esse modelo de arquitetura é um 
modelo seqüencial em lote, comum para sistemas de 
processamento de dados, como sistemas de cobrança. Sistemas de 
processamento de dados geram normalmente muitos relatórios de 
saída derivados de processamentos simples sobre uma grande 
quantidade de registros de entrada. Um exemplo desse tipo de 
arquitetura de sistema é ilustrada na Figura 4.7. 
 
 
Figura 4.7–Modelo de fluxo de dados de um sistema de processamento de 
faturas (Fonte: Sommerville, 2007). 
 
3.2.2.2 Arquitetura orientada a objetos 
152
 
Um modelo de arquitetura orientada a objetos estrutura o 
sistema em um conjunto de objetos não firmemente acoplados com 
interfaces bem definidas onde os objetos chamam serviços 
oferecidos por outros objetos. A decomposição orientada a objetos 
está relacionada a classes de objetos, seus atributos e suas 
operações. Quando implementados, os objetos são criados a partir 
dessas classes e algum modelo de controle é usado para coordenar 
as operações de objetos. A Figura 4.8 ilustra um exemplo de 
modelo de arquitetura orientada a objetos de um sistema de 
processamento de faturas. 
 
 
Figura 4.8–Modelo de objeto de um sistema de processamento de faturas 
(Fonte: Sommerville, 2007). 
 
3.2.3 Arquiteturas de referência 
Os modelos de arquitetura descritos anteriormente são 
modelos gerais e podem ser aplicados em muitas classes de 
aplicações. Assim como esses modelos gerais, modelos de 
arquitetura específicos a determinado domínio de aplicação podem 
ser usados. Embora as instâncias desses sistemas sejam diferentes 
em detalhes, a estrutura comum de arquitetura pode ser reusada no 
desenvolvimento de novos sistemas. Esses modelos de arquitetura 
153
são chamados de arquiteturas de domínio específico e são 
divididos em dois tipos: 
● Modelos genéricos: são abstrações de uma série de 
sistemas reais e englobam as características principais 
desses sistemas. Por exemplo, em sistemas de tempo 
real, pode haver modelos genéricos de arquitetura de 
tipos de sistemas diferentes, como sistemas de coleta 
de dados ou sistemas de monitoração. 
● Modelos de referência: são mais abstratos e descrevem 
uma classe maior de sistemas. Fornecem informações 
aos projetistas sobre a estrutura geral dessa classe de 
sistema. Os modelos de referência são geralmente 
derivados de um estudo do domínio de aplicação. 
Representam uma arquitetura idealizada que inclui 
todas as características que esses sistemas podem 
incorporar. 
 
As arquiteturas de referência geralmente não são consideradas 
um roteiro de implementação. Em vez disso, sua principal função é 
ser um meio de discussão de arquiteturas de domínio específico e 
de comparação de sistemas diferentes em um domínio. Um modelo 
de referência forneceum vocabulário para comparação e atua como 
uma base, em relação à qual os sistemas podem ser avaliados. O 
modelo OSI é um exemplo de arquitetura de modelo de referência. 
 
3.3 Projeto de interface 
 
O projeto de interface descreve como o software se comunica 
com os sistemas que operam com ele e com as pessoas que o 
utilizam. Uma interface implica um fluxo de informação (dados e/ou 
154
controle) e um tipo de comportamento específico. Assim, os 
cenários de uso e modelos comportamentais fornecem muito da 
informação necessária para o projeto da interface. 
Os elementos do projeto de interface de software “contam-nos” 
como a informação flui para dentro e para fora do sistema e como 
ela é disseminada entre os componentes definidos como parte da 
arquitetura. Há três importantes elementos do projeto de interface: 
a) interfaces internas entre vários componentes de projeto; b) 
interfaces externas com outros sistemas, dispositivos, redes ou 
outros produtores ou consumidores de informação; e c) a interface 
com o usuário (IU); Esses elementos do projeto de interface 
permitem ao software comunicar-se externamente e possibilitam 
comunicação interna e colaboração entre os componentes que 
compõem a arquitetura do software. 
O projeto de interfaces internas é alinhado juntamente com o 
projeto de componentes. As realizações de projeto das classes de 
análise representam todas as operações e esquemas de mensagem 
necessários para permitir comunicação e colaboração entre 
operações de várias classes. Cada mensagem deve ser projetada 
para acomodar a transferência de informação necessária e os 
requisitos funcionais específicos da operação solicitada. 
O projeto de interfaces externas requer informação definitiva 
sobre a entidade para qual a informação é enviada ou recebida. Em 
todo caso, essa informação deveria ser coletada durante a 
engenharia de requisitos e verificada quando o projeto de interface 
começa. O projeto de interfaces externas deve incorporar verificação 
de erros e (quando necessário) características de segurança 
adequadas. 
O projeto de IU é uma ação importante de engenharia de 
software, pois incorpora elementos estéticos (layout, cor, gráficos, 
155
mecanismos de interação), elementos ergonômicos (disposição e 
localização da informação, metáforas, navegação pela IU) e 
elementos técnicos (padrões de IU, componentes reusáveis). 
A interface com o usuário é um processo iterativo no qual os 
usuários interagem com os projetistas e os protótipos de interface 
para decidir sobre as características, a organização e a aparência da 
interface com o usuário do sistema. Algumas vezes, o protótipo da 
interface é desenvolvido separadamente, em paralelo, com outras 
atividades de engenharia de software. Mais comumente, em 
especial quando o desenvolvimento iterativo é usado, o projeto de 
interface com o usuário prossegue incrementando-se, à medida que 
o software é desenvolvido. Em ambos os casos, contudo, antes de 
iniciar a programação, devemos ter desenvolvido e testado alguns 
projetos baseados em papel. O processo geral de IU é ilustrado na 
Figura 4.9 
 
Figura 4.9–Processo de projeto de Interface do usuário (Fonte: Sommerville, 
2007). 
 
Entre as atividades do processo de projeto de interface, 
destacamos três principais: 
 
1) Análise de usuário: no processo de análise de usuário, 
156
devemos desenvolver uma compreensão das tarefas que os 
usuários realizam, seu ambiente de trabalho, os outros 
sistemas que eles usam, como eles interagem com outras 
pessoas em seu trabalho, etc. Para produtos com vários 
usuários, devemos tentar desenvolver essa compreensão por 
meio do foco em grupos, ensaios com usuários potenciais e 
exercícios similares. 
2) Prototipação de sistema: o projeto e desenvolvimento da 
interface com o usuário é um processo iterativo. Embora os 
usuários possam informar sobre os recursos de interface de 
que necessitam, é muito difícil para eles serem específicos 
até que vejam algo tangível. Portanto, devemos desenvolver 
de protótipos do sistema e expô-los aos usuários, que 
poderão, então, guiar a evolução da interface. 
3) Avaliação de interface: além das discussões com os 
usuários durante o processo de prototipação, devemos ter 
também uma atividade de avaliação mais formalizada, na 
qual sejam coletadas informações sobre a experiência do 
usuário com a interface. 
 
Uma interface com o usuário deve integrar a interação do 
usuário e apresentação de informações mais apropriadas para a 
aplicação, os conhecimentos e as experiências dos usuários do 
sistema, e o equipamento disponível. 
 
3.3.1 Interação do usuário 
A interação do usuário significa emitir comandos e dados 
associados ao sistema de computador. Nos primeiros computadores, 
a única forma de fazer isso era por meio de uma interface de linha 
de comando, e uma linguagem de propósito especial era usada para 
157
se comunicar com a máquina. Entretanto, isso era utilizado por 
usuários especialistas e uma serie de abordagens desenvolvidas 
são atualmente mais fáceis de usar. Podemos classificar essas 
formas de interação em cinco estilos primários: 
1) Manipulação direta: o usuário interage diretamente com os 
objetos da tela. A manipulação direta envolve, geralmente, 
um dispositivo apontador (um mouse ou o próprio dedo sobre 
telas sensíveis a toque), que indica o objeto a ser 
manipulado, e a ação, que especifica o que deve ser feito com 
esse objeto. Por exemplo, para excluir um arquivo, podemos 
clicar sobre um ícone que representa esse arquivo e arrastá-lo 
para um ícone de lixeira. 
2) Seleção de menu: o usuário seleciona um comando de uma 
lista de possibilidades (um menu). O usuário pode também 
selecionar um outro objeto da tela por manipulação direta e o 
comando opera sobre esse objeto. Nessa abordagem, para 
excluir um arquivo, devemos selecionar o ícone de arquivo e 
selecionar o comando de exclusão. 
3) Preenchimento de formulários: o usuário preenche os campos 
de um formulário. Alguns campos podem ter menus 
associados e o formulário pode ter botões de ação que, 
quando pressionados, causam o inicio de alguma ação. Não é 
aconselhável usar normalmente essa abordagem para 
implementar a interface de operações, como excluir um 
arquivo. Se fizermos dessa forma, isso envolverá o 
preenchimento do nome do arquivo no formulário e, depois, 
pressionar um botão para excluir. 
4) Linguagem de comando: o usuário emite um comando especial 
e parâmetros associados para instruir o sistema sobre o que 
fazer. Para excluir um arquivo, devemos digitar um comando 
158
para excluir com o nome do arquivo como parâmetro. 
5) Linguagem natural: o usuário emite um comando em 
linguagem natural. Esse geralmente é o estágio inicial de uma 
linguagem de comando; a linguagem natural é analisada e 
traduzida em comandos de sistema. Para excluir um arquivo, 
podemos digitar “excluir o arquivo denominado xxx”. 
 
Cada um desses estilos de interação tem vantagens e 
desvantagens e é mais adequado a determinado tipo de aplicação eusuário. A Tabela 4.1 mostra as principais vantagens e 
desvantagens desses estilos e sugere tipos de aplicações em que 
eles poderiam ser usados. 
 
 
Estilo de 
interação 
Principais 
vantagens 
Principais 
desvantagens 
Exemplos de 
aplicação 
Manipulação 
direta 
Interação rápida e 
intuitiva; 
Facilidade de 
aprendizado 
Pode ser difícil 
implementar; 
É adequado somente 
quando houver uma 
metáfora visual para 
tarefas e objetos 
Jogos de vídeo; 
Sistemas CAD 
 
Seleção de menu Evita erros do 
usuário; 
É necessária 
pouca digitação 
Lento para usuários 
experientes; 
Pode tornar-se 
complexo se houver 
muitas opções de 
menus 
A maioria dos 
sistemas de 
propósito geral 
Preenchimento 
de formulários; 
Facilidade de 
aprendizado 
verificável 
Entrada de dados 
simples 
Ocupa grande 
quantidade de 
espaço de tela; 
Causa problemas 
quando as opções 
de usuário não 
combinam com os 
campos de 
formulário 
Controle de 
estoque; 
Processamento de 
empréstimos 
pessoais 
159
Linguagem de 
comando 
Poderosa e flexível Dificuldade de 
aprendizado; 
Gerenciamento 
inadequado de erros 
Sistemas 
operacionais; 
Sistemas de 
comando e 
controle 
Linguagem 
natural 
Acessível a 
usuários casuais; 
Facilmente 
estendido 
Requer muita 
digitação; 
Não são confiáveis 
Sistemas de 
recuperação de 
informações 
 
Tabela 4.1–Vantagens e desvantagens de estilos de interação. 
 
Para ilustrar o projeto de interação com o usuário utilizamos, 
como exemplo, um sistema de controle de livros de uma biblioteca 
na qual os usuários podem acessar documentos de outras 
bibliotecas. A interface com o usuário do sistema é implementada 
por meio de um navegador web e, assim, considerando que os 
usuários devem fornecer informações ao sistema, como o 
identificador do documento, seu nome e seus detalhes de 
autorização, faz sentido usar uma interface baseada em 
formulários. A Figura 4.10 ilustra um possível projeto de interface 
para o componente de busca do sistema. 
 
Figura 4.10–Interface baseada em formulários (Fonte: Sommerville, 2007). 
 
160
 
3.3.2 Apresentação de informações 
Todos os sistemas interativos têm de fornecer algum modo de 
apresentação de informações aos usuários. A apresentação de 
informações pode ser simplesmente uma representação direta de 
informações de entrada (por exemplo, texto em um processador de 
texto) ou pode apresentar as informações graficamente. Uma boa 
diretriz de projeto é manter o software necessário para 
apresentação de informações separado das informações em si. A 
separação do sistema de apresentação dos dados permite alterar a 
representação na tela do usuário sem ter de alterar a base do 
sistema computacional, como ilustra a Figura 4.11. 
 
Figura 4.11–Apresentação de informações (Fonte: Sommerville, 2007). 
 
A abordagem Modelo-Visão-Controle (MVC) ilustrada na Figura 
4.12 é uma maneira eficiente de apoiar as várias apresentações de 
dados. Os usuários podem interagir com cada apresentação em um 
estilo apropriado à apresentação. Os dados a serem exibidos são 
encapsulados por um objeto de modelo. Cada objeto de modelo 
pode ter uma série de objetos de visualização separados, 
associados a ele, sendo cada visualização uma apresentação de 
display diferente do modelo. 
161
 
Figura 4.12–Modelo MVC de interação com o usuário (Fonte: Sommerville, 
2007). 
 
Por exemplo, considere um sistema que registra e resume os 
valores de vendas mensais de uma empresa. A Figura 4.13 ilustra 
como as mesmas informações podem ser apresentadas em forma de 
texto ou graficamente. Os gerentes que estudam os valores de 
vendas estão, geralmente, mais interessados nas tendências ou 
números anômalos em vez de em valores precisos. A apresentação 
gráfica dessas informações como um histograma destaca os 
números anômalos, em março e maio, dos outros. A Figura 4.13. 
Ilustra também como a apresentação textual ocupa menos espaço 
do que uma representação gráfica das mesmas informações. 
162
 
Figura 4.13–Apresentações alternativas de informações (Fonte: Sommerville, 
2007). 
 
 
3.4 Projeto em nível de componentes 
 
Definido de forma geral, o componente é um bloco construtivo 
modular para software de computador que encapsula implementação 
e exibe conjunto de interfaces. O projeto em nível de componente 
transforma elementos estruturais da arquitetura de software em 
uma descrição procedural dos componentes de software. A 
informação obtida do modelo baseado em classes, modelos de fluxo 
e modelos comportamentais serve de base para o projeto de 
componentes. 
O projeto em nível de componente do software descreve 
completamente os detalhes internos de cada componente de 
software. Para tanto, o projeto define estruturas de dados para 
todos os objetos de dados locais e detalhes algorítmicos para todo 
o processamento que ocorre em um componente e em uma interface 
que dá acesso a todas as operações do componente 
163
(comportamentos). 
Os detalhes de projeto de um componente podem ser 
modelados em muitos níveis diferentes de abstração. Um diagrama 
de atividade pode ser usado para representar a lógica de 
processamento. O fluxo procedural detalhado de um componente 
pode ser representado por meio de pseudocódigo ou de algumas 
formas diagramáticas (diagrama de atividade ou fluxograma). 
 
3.5 Projeto em nível de implantação 
Elementos de projeto em nível de implantação indicam como a 
funcionalidade e os subsistemas do software serão alocados no 
ambiente computacional físico que vai apoiar o software. Durante o 
projeto, um diagrama de implantação UML é desenvolvido e refinado 
como mostra a Figura 4.14, onde três ambientes computacionais 
são apresentados. Os subsistemas (funcionalidade) alojados em 
cada elemento computacional são indicados. Por exemplo, o 
“computador pessoal” aloja subsistemas que implementam 
segurança, vigilância, gestão residencial e características de 
comunicação. Além disso, um subsistema de acesso externo foi 
projetado para gerir todas as tentativas de acesso ao sistema de 
uma fonte externa. Cada subsistema seria elaborado parta indicar 
os componentes que ele implementa. 
 
164
 
Figura 4.14–Diagrama de implantação UML (Fonte: Pressman, 2006). 
 
O diagrama acima ilustrado está na forma de descritor, ou 
seja, ele mostra o ambiente computacional, mas não indica 
explicitamente detalhes de configuração. Por exemplo, o 
“computador pessoal” não é melhor identificado. Ele poderia ser um 
PC Windows ou um Macintosh, uma estação de trabalho Sun ou 
Linux. Esses detalhes são fornecidos quando o diagrama de 
implantação é revisitado na forma de instância durante estágios 
posteriores do projeto ou quando a construção começa. Cada 
instância da implantação (uma configuração de hardware específica, 
a qual é atribuído um nome) é identificada. Veremos um pouco mais 
sobre diagramas de implantação na Seção 5 desta Unidade. 
 
4. Modelagem de projeto utilizando o RUP 
 
O propósito do projeto é adaptar os resultados da análise às 
restrições impostas pelos requisitos não funcionais, o ambiente de 
implementação, os requisitos de desempenho e assim 
165
sucessivamente. O projeto é um refinamento da análise e objetiva 
assegurar a coberturacompleta dos requisitos. 
 
4.1 Atividades 
 
Nas iterações ocorridas durante a fase de projeto, a plataforma 
arquitetônica do sistema está definida e estabilizada, e a ênfase 
agora está na adição de mais funcionalidades da aplicação. A Figura 
4.15 ilustra o fluxo de atividades relacionadas à Análise e Projeto, 
consideradas como uma disciplina única pelo RUP, mas cuja 
abordagem é feita separadamente nesta Unidade 4. 
 
Figura 4.15 – Fluxo de Atividades de Projeto, em destaque (Fonte: adaptado 
de www.funpar.ufpr.br). 
 
● Refinar a arquitetura: este detalhe de fluxo é composto de 
atividades como identificar mecanismos de projeto, identificar 
elementos de projeto existentes, descrever arquitetura de 
166
execução e descrever distribuição, todas executadas pelo 
arquiteto, e a revisão da arquitetura, executada pelo revisor 
de arquitetura. O propósito deste detalhe de fluxo é: 
➢ Fornecer a transição natural das atividades de análise 
para as atividades de projeto, identificando: a) os 
elementos de projeto apropriados dos elementos de 
análise e b) os mecanismos de projeto apropriados dos 
mecanismos de análise relacionados. 
➢ Manter a consistência e integridade da arquitetura, 
assegurando que: a) os novos elementos de projeto 
identificados para a iteração atual estejam integrados 
com os elementos de projeto preexistentes e b) a 
reutilização máxima de componentes de componentes 
disponíveis e de elementos de projeto seja alcançada, 
assim que possível, no trabalho de projeto. 
➢ Descrever a organização da execução do sistema e a 
arquitetura de distribuição. 
➢ Organizar o modelo de implementação para fazer a 
transição entre o projeto e a implementação sem 
interrupções. 
 
● Projetar componentes: este detalhe do fluxo é composto das 
atividades análise de caso de uso, executada pelo projetista, 
identificar elementos do projeto, executada pelo arquiteto, e 
revisão do projeto, executada pelo revisor do projeto. O 
propósito deste detalhe do fluxo é: 
➢ Refinar as definições dos elementos de projeto, 
resultando nos detalhes de como os elementos de 
projeto implementam o comportamento requerido. 
➢ Refinar e atualizar as realizações de caso de uso 
167
baseando-se em novos elementos de projetos 
introduzidos, mantendo assim atualizadas as 
realizações de caso de uso. 
➢ Revisar o projeto quanto à sua evolução. 
Neste detalhe do fluxo, as características e relações de classe, 
as interfaces de subsistema e suas realizações pelas classes 
contidas e as realizações de caso de uso em termos de 
colaborações, são todas completamente especificadas. 
● Projetar banco de dados: este detalhe do fluxo é opcional, 
invocado quando o sistema envolve uma quantidade grande 
de dados em um banco de dados. É composto das atividades 
projetar banco de dados, executada pelo projetista de banco 
de dados, projetar classe, executada pelo projetista e revisar 
o projeto, executada pelo revisor de projeto. O propósito 
deste detalhe do fluxo é: 
➢ Identificar as classes persistentes no projeto. 
➢ Projetar a estrutura de banco de dados apropriada para 
armazenar as classes persistentes. 
➢ Definir os mecanismos e estratégias para a 
armazenagem e restauração dos dados persistentes, de 
tal modo que sejam satisfeitos os critérios para o 
desempenho do sistema. 
Podemos observar, na Figura 4.15, que o projeto de 
componente e o de banco de dados ocorrem em paralelo: pode 
haver muitas interações entre desenvolvedores executando estes 
fluxos. Por exemplo, a descoberta de uma nova classe pode exigir 
ajuste na arquitetura. O refinamento da arquitetura por razões de 
desempenho também pode impactar o projeto de classes 
persistentes. 
 
168
4.2 Papéis 
O RUP expressa o processo de projeto de sistemas em termos 
de atividades (como já visto), papéis e artefatos. A Figura 4.16 
ilustra os papéis e os artefatos envolvidos nesta fase. Os papéis 
principais envolvidos no projeto são: 
● Projetista: define as responsabilidades, operações, atributos e 
relações de uma ou várias classes, e determina como elas 
devem ser ajustadas ao ambiente de implementação. Além 
disso, o projetista pode ter responsabilidade por um ou mais 
pacotes de projeto ou subsistemas de projeto, inclusive sobre 
quaisquer classes contidas nos pacotes ou subsistemas. 
● Projetista de banco de dados (opcional): é requisitado quando 
o sistema que estiver sendo projetado incluir um banco de 
dados. 
● Projetista de cápsula (para sistemas em tempo real): se 
concentra em assegurar que o sistema possa responder a 
eventos de maneira pontual, por meio da utilização apropriada 
de técnicas coordenadas de projeto. 
● Revisor de arquitetura e de projeto: estes especialistas 
revisam os artefatos fundamentais produzidos por este fluxo. 
 
Figura 4.16 – Papéis e artefatos do Projeto (Fonte: www.funpar.ufpr.br). 
 
4.3 Artefatos 
● Realização de casos de uso: descreve como determinado 
caso de uso é realizado no modelo de design em termos 
de objetos de colaboração. 
169
● Subsistema de projeto: é um elemento de modelo que 
tem a semântica de um pacote (pode conter outros 
elementos de modelo) e a uma classe (apresenta um 
comportamento). O comportamento do subsistema é 
definido por classes ou outros subsistemas contidos 
nele. Um subsistema realiza uma ou mais interfaces, 
que definem o comportamento que ele pode apresentar. 
● Pacote do projeto: é um conjunto de classes, 
relacionamentos, realizações de casos de uso, 
diagramas e outros pacotes. Ele é usado para estruturar 
o modelo de design, dividindo-o em partes menores. 
● Classe do projeto: é uma descrição de um conjunto de 
objetos que compartilham as mesmas 
responsabilidades, relacionamentos, operações, 
atributos e semântica. 
● Classe de análise: representa um primeiro modelo 
conceitual para "elementos no sistema que possuam 
responsabilidades e comportamento". 
● Modelo de dados: é um subconjunto do modelo de 
implementação que descreve a representação lógica e 
física dos dados persistentes no sistema. Também 
abrange qualquer comportamento definido no banco de 
dados, como procedimentos armazenados, triggers, 
restrições etc. 
● Cápsula: é um padrão de design específico que 
representa um thread de controle encapsulado no 
sistema. 
 
 
 
170
 
 
5. Modelagem de projeto utilizando diagramas UML 
Quando deixamos de ter uma visão conceitual da construção de 
classes e de diagramas de seqüência em uma determinada 
abstração, começamos a focar o workflow de projeto de sistemas. 
Por vezes os dois workflows (análise e projeto) são abordados como 
um único (RUP, por exemplo). No entanto, para fins didáticos, 
abordamos essas duas etapas separadamente. Nesta Seção, que 
trata a etapa de projeto por meio da UML, nosso foco está nos 
diagramas de componentes, implantação e colaboração. 
 
5.1 Diagrama de componentes 
Os componentes são um importante bloco de construção para a 
modelagem de aspectos físicos de um sistema. Um componente é a 
parte física e substituível de um sistema ao qual se adapta e 
fornece a realização de um conjunto de interfaces. Graficamente, é 
representadocomo um retângulo com abas, como ilustrado na 
Figura 4.17. 
 
 
Figura 4.17–Ilustração de componente (Fonte: BOOCH et. al.,2000). 
 
 
Em muitos aspectos, os componentes são semelhantes às 
classes: ambos têm nomes; ambos podem realizar um conjunto de 
interfaces; ambos podem participar de um relacionamento de 
171
dependência, generalização e associação; ambos admitem 
instâncias; ambos podem ser participantes de interações. 
Entretanto, existem algumas diferenças significativas entre 
componentes e classes: 
● As classes representam abstrações lógicas; os 
componentes representam coisas físicas que vivem no 
mundo dos bits. Em resumo, os componentes podem 
viver em nós, as classes não. 
● Os componentes representam o pacote físico de 
componentes lógicos e se encontram em um nível 
diferente de abstração. 
● As classes podem ter atributos e operações 
diretamente. Em geral, os componentes somente têm 
operações que são alcançadas por meio de suas 
interfaces. (BOOCH,344) 
 
Três tipos de componentes podem ser diferenciados: 
Primeiro, existem componentes de implantação. São os 
componentes necessários e suficientes para formar um sistema 
executável, como as bibliotecas dinâmicas (DLLs) e os executáveis 
(EXEs). Segundo, existem os componentes do produto de trabalho, 
que são essencialmente o resíduo do processo de desenvolvimento, 
formados por coisas como arquivos de código-fonte e arquivos de 
dados a partir dos quais os componentes de implantação são 
criados. Terceiro, existem os componentes de execução, criados 
como uma consequência de um sistema de execução, como um 
objeto COM+, que é instanciado a partir de uma DLL. 
Os diagramas de componentes são empregados para a 
modelagem da visão estática de implementação de um sistema. 
Isso envolve a modelagem de itens físicos que residem em um nó, 
172
como executáveis, bibliotecas, tabelas, arquivos e documentos. Os 
diagramas de componentes são essencialmente diagramas de 
classes que focalizam os componentes de um sistema, conforme 
ilustra a Figura 4.18. 
 
 
 
Figura 4.18–Diagrama de componentes (Fonte: BOOCH et. al.,2000). 
 
Ao criarmos diagramas de componentes na UML, devemos 
lembrar que todo diagrama de componentes é apenas uma 
apresentação gráfica da visão estática de implementação de um 
sistema. Isso significa que um único diagrama de componentes não 
precisará capturar tudo sobre a visão de implementação do sistema. 
Coletivamente, todos os diagramas de componentes representam a 
visão estática de implementação completa; individualmente, cada 
diagrama representa apenas um único aspecto. 
Um diagrama de componentes bem estruturado: 
● Tem como foco comunicar um aspecto da visão estática 
de implementação do sistema. 
● Contém somente os elementos essenciais à 
173
compreensão desse aspecto. 
● Fornece detalhes consistentes com seu nível de 
abstração, mostrando somente os adornos essenciais à 
compreensão do que é apresentado. 
● Não é tão minimalista que informa mal o leitor sobre a 
semântica importante. 
 
Ao definir um diagrama de componentes: 
● Dê-lhe um nome capaz de comunicar seu propósito. 
● Distribua seus elementos para minimizar o cruzamento 
de linhas. 
● Organize seus elementos espacialmente, de modo que 
os itens semanticamente afins fiquem próximos 
fisicamente. 
● Use notas e cores como indicações visuais com a 
finalidade de chamar a atenção para características 
importantes de seu diagrama. 
● Use elementos estereotipados com cuidado. Escolha um 
pequeno conjunto de ícones comuns para seu projeto ou 
organização e utilize-os de maneira consistente. 
 
5.2 Diagrama de implantação 
Assim como os componentes, os nós vivem no mundo material 
e são um bloco de construção importante para a modelagem dos 
aspectos físicos de um sistema. Um nó é um elemento físico que 
existe em tempo de execução e representa um recurso 
computacional, geralmente tendo pelo menos alguma memória e, 
frequentemente, capacidade de processamento. Graficamente, um 
nó é representado por um cubo, como ilustra a Figura 4.19. 
174
 
Figura 4.19–Ilustração de um nó (Fonte: BOOCH et. al.,2000). 
 
Os diagramas de implantação são empregados para a 
modelagem da visão estática da implementação de um sistema. Na 
maior parte, isso envolve a modelagem da topologia do hardware 
em que o sistema é executado. Os diagramas de implantação são 
essencialmente diagramas de classes que focalizam os nós do 
sistema, como ilustra a Figura 4.20. No limite do software e do 
hardware, eles são utilizados para analisar a topologia dos 
processadores e dispositivos nos quais o software é executado. 
 
Figura 4.20–Diagrama de implantação (Fonte: BOOCH et. al.,2000). 
 
Os diagramas de implantação são úteis por facilitarem a 
comunicação entre os engenheiros de hardware e os 
175
desenvolvedores de software do projeto. Com a utilização de nós 
estereotipados para se parecerem com dispositivos familiares, 
podemos criar diagramas compreensíveis pelos dois grupos. Os 
diagramas de implantação também são úteis para a análise de 
compatibilidade de hardware e software. Podendo ser utilizados 
para visualizar, especificar, construir e documentar as decisões de 
engenharia de sistema. 
Existem alguns tipos de sistemas para os quais os diagramas 
de funcionamento são desnecessários. Se estivermos 
desenvolvendo um trecho de software que reside em uma única 
máquina e interage somente com dispositivos padrão dessa 
máquina, que já são gerenciados pelo sistema operacional host (por 
exemplo, o teclado, o monitor e o modem de um computador 
pessoal), podemos ignorar os diagramas de implantação. Por outro 
lado, se estivermos desenvolvendo um trecho de software que 
interage com dispositivos que o sistema operacional host 
tipicamente não gerencia ou que é distribuído fisicamente por vários 
processadores, então o uso de diagramas de implantação ajudará a 
analisarmos o mapeamento de software-para-hardware do sistema. 
Ao fazermos a modelagem da visão estática de implantação de 
um sistema, geralmente utilizaremos os diagramas de implantação 
em uma das três maneiras: 
● Para fazer a modelagem de sistemas embarcados. 
● Para fazer a modelagem de sistemas cliente / servidor. 
● Para fazer a modelagem de sistemas totalmente 
distribuídos. 
 
5.2.1 Modelagem de um sistema embarcado 
O desenvolvimento de um sistema embarcado é bem mais do 
que um problema de software. É preciso gerenciar o mundo físico 
176
onde se encontram as partes móveis em que ele se divide, os sinais 
têm ruídos e o comportamento não é linear. Ao fazer a modelagem 
de um desses sistemas, é necessário levar em consideração sua 
interface com o mundo real e isso significa analisar dispositivos 
pouco usuais, além dos nós. 
Por exemplo, a Figura 4.21 ilustra o hardware para um robô 
autônomo simples. Existe um nó (Pentium motherboard) 
estereotipado como um processador. Ao redor desse nó existem oito 
dispositivos, cada um estereotipado como um dispositivo e 
representado por um ícone que oferece uma clara indicação visual 
ao seu equivalente do mundo real. 
 
 
Figura 4.21–Modelagem de um sistema embarcado(Fonte: BOOCH et. 
al.,2000). 
 
 
5.2.2 Modelagem de um sistema cliente / servidor 
A divisão de um sistema em partes cliente e servidor envolve a 
tomada de algumas decisões difíceis a respeito do local em que 
177
serão colocados fisicamente seus componentes de software e como 
uma distribuição equilibrada de responsabilidades entre esses 
componentes. Por exemplo, a maioria dos sistemas de informações 
de gerenciamento são essencialmente arquiteturas tripartidas, 
significando que a GUI, a lógica do negócio e o banco de dados do 
sistema são distribuídos fisicamente. Costuma ser óbvio decidir 
onde colocar a GUI e o banco de dados; portanto, a parte mais 
difícil é a decisão de onde a lógica do negócio ficará. 
A Figura 4.22 ilustra a topologia de um sistema de recursos 
humanos, que segue uma arquitetura cliente/ servidor clássica. O 
pacote cliente contém dois nós (console e kiosk), ambos 
estereotipados e visualmente diferenciados. O pacote servidor 
contém dois tipos de nós (caching server e server) e ambos têm, 
como adornos, alguns dos componentes que residem em cada um 
deles. Observe também que caching server e server estão marcados 
com multiplicidades explícitas, especificando quantas instâncias de 
cada um são esperadas em uma determinada configuração de 
instalação. 
 
 
Figura 4.22–Modelagem de um sistema cliente/ servidor (Fonte: BOOCH et. 
al.,2000). 
 
5.2.3 Modelagem de um sistema totalmente distribuído 
Os sistemas distribuídos aparecem de muitas formas, desde 
178
sistemas simples com dois processadores até os que estão em 
muitos nós dispersos geograficamente. Os nós são adicionados e 
removidos, à medida que o tráfego da rede se modifica e os 
processadores falham; novos e mais rápidos caminhos de 
comunicação podem ser estabelecidos em paralelo com os canais 
anteriores e mais lentos, que eventualmente são desativados. Não 
apenas a topologia desses sistemas poderá mudar, mas a 
distribuição de seus componentes de software também poderá ser 
alterada. 
A Figura 4.23 ilustra a topologia de um sistema totalmente 
distribuído. Existem três consoles (instâncias anônimas do nó 
estereotipado console), que estão vinculados à Internet 
(claramente um nó de uma única função). Por sua vez, existem três 
instâncias de servidores regionais, que servem como front-ends de 
servidores nacionais, somente um dos quais é mostrado. 
 
 
Figura 4.23–Modelagem de um sistema totalmente distribuído (Fonte: BOOCH 
et. al.,2000). 
 
5.2.4 Recomendações para diagramação de implantação 
Um diagrama de implantação bem estruturado: 
● Tem como foco a comunicação de um aspecto da visão 
179
estática de implantação do sistema. 
● Contém somente os elementos essenciais à 
compreensão desse aspecto. 
● Fornece detalhes consistentes com seu nível de 
abstração; exibe somente os adornos essenciais à 
compreensão. 
● Não é tão minimalista que acabe informando mal o leitor 
sobre a semântica importante. 
 
Ao definir um diagrama de implantação: 
● Dê-lhe um nome capaz de comunicar seu propósito. 
● Distribua os elementos de forma a minimizar o 
cruzamento de linhas. 
● Organize seus elementos espacialmente, de modo que 
os itens que são semanticamente afins fiquem próximos 
fisicamente. 
● Use notas e cores como indicações visuais com a 
finalidade de chamar atenção para características 
importantes de seu diagrama. 
● Use elementos estereotipados com cuida. Escolha um 
pequeno conjunto de ícones comuns para seu projeto ou 
organização e use-os de forma consistente. 
 
5.3 Diagrama de colaboração 
 
Um diagrama de colaboração é um diagrama de interação que 
dá ênfase à organização estrutural dos objetos que enviam e 
recebem mensagens. Graficamente, um diagrama de colaboração é 
uma coleção de vértices e arcos. Conforme ilustra a Figura 4.24, um 
diagrama de colaboração é formado colocando primeiro os objetos 
180
que participam da interação como os vértices de um gráfico. A 
seguir, representa os vínculos que conectam esses objetos como os 
arcos do gráfico. Por fim, adorna esses vínculos com as mensagens 
que os objetos enviam e recebem. Isso proporciona ao leitor uma 
clara indicação visual do fluxo de controle no contexto da 
organização estrutural dos objetos que colaboram. 
 
 
 
Figura 4.24–Diagrama de colaboração (Fonte: BOOCH et. al.,2000). 
 
Os diagramas de colaboração têm duas características que os 
diferenciam dos diagramas de sequência. Primeiro, existe o 
caminho, e para indicar como um objeto está vinculado a outro, 
podemos anexar um estereótipo de caminho à extremidade contrária 
de um vínculo. Segundo, existe o número de sequência. Para indicar 
a ordem temporal de uma mensagem, use um número como prefixo 
da mensagem, aumentando unitariamente para cada nova 
mensagem no fluxo de controle. Devemos observar também que, no 
mesmo vínculo, é possível exibir muitas mensagens e cada uma 
terá um número de sequência único. 
Um diagrama de colaboração bem estruturado: 
181
● Está voltado para comunicar um único aspecto da dinâmica do 
sistema. 
● Contém somente os elementos essenciais à compreensão 
desses aspectos. 
● Fornece detalhes consistentes com seu nível de abstração e 
expõe somente os adornos essenciais à compreensão. 
● Não é tão minimalista, que informe mal ao leitor sobre a 
semântica que é importante. 
 
Ao definir um diagrama de colaboração: 
● Dê-lhe um nome capaz de comunicar seu propósito. 
● Dê ênfase à ordenação temporal das mensagens. 
● Distribua seus elementos para minimizar o cruzamento de 
linhas. 
● Use notas e cores como indicações visuais para chamar 
atenção para características importantes do diagrama. 
● Use a ramificação com cautela; você pode representar bem 
melhor as ramificações complexas, utilizando os diagramas de 
atividades. 
 
 
6. Ferramentas para modelagem de projeto 
 
6.1 Projeto arquitetural 
Ferramentas de projeto arquitetural modelam a estrutura de 
software pela representação dos componentes de interface, 
dependências e relacionamentos, e interações. A mecânica da 
ferramenta varia e, na maioria dos casos, a capacidade do projeto 
arquitetural é parte da funcionalidade fornecida por ferramentas 
automatizadas para modelagem de análise e de projeto. 
182
As seguintes ferramentas suportam a modelagem estrutural do 
software: 
● Adalon: é uma ferramenta de projeto especializada para 
projeto e construção de arquiteturas específicas de 
componentes baseados na web. 
● ObjectIF: é uma ferramenta de projeto baseada na UML 
que leva as arquiteturas (por exemplo, Coldfusion, J2EE, 
Fusebox) de uso fácil para engenharia de software 
baseada em componentes. 
● Rational Rose: é uma ferramenta de projeto baseada na 
UML que suporta todos os aspectos do projeto 
arquitetural. 
 
6.2 Projeto em nível de componentes 
 
Um dos elementos-chave que conduz ao sucesso ou falha do 
desenvolvimento do software baseado em componentes é a 
disponibilidade de middleware. Middleware é uma coleção de 
componentes de infraestrutura que permitem aos componentes do 
domínio do problema comunicarem-se entre eles mesmos, em uma 
rede ou dentro de um sistema complexo. Três normas concorrentesestão disponíveis aos engenheiros de software que querem usar 
engenharia de software baseada em componentes como seu 
processo de software: 
● OMG CORBA (http://www.corba.org) 
● Microsoft COM 
(http://www.microsoft.com/com/tech/complus.asp) 
● Sun JavaBeans (http://java.sun.com/products/ejb/) 
 
Os sites mencionados apresentam grande quantidade de 
183
http://www.google.com/url?q=http%3A%2F%2Fwww.corba.org&sa=D&sntz=1&usg=AFQjCNGxJuCNMSZRgwfzZgOmuyR0tik5MA
http://www.google.com/url?q=http%3A%2F%2Fwww.microsoft.com%2Fcom%2Ftech%2Fcomplus.asp&sa=D&sntz=1&usg=AFQjCNHK7CuS-GBZTUsWw_jZ3PXTDRllKg
http://www.google.com/url?q=http%3A%2F%2Fjava.sun.com%2Fproducts%2Fejb%2F&sa=D&sntz=1&usg=AFQjCNE9T7QYoEeuwbvgpII6_m5xg5Xwzw
tutoriais,papers, ferramentas e recursos gerais sobre essas 
importantes normas de middleware (PRESSMAN, 243). 
Uma grande variedade de ferramentas UML está disponível 
para apoiar o projetista em todos os níveis de projeto. Algumas 
delas fornecem suporte à Linguagem de Restrição de Objetos 
(OCL): 
● ArgoUML: suporta UML completa e OCL e inclui uma 
variedade de ferramentas de apoio a projetos que vai 
além da geração de diagramas UML e expressões OCL. 
● Dresden OCL toolkit: é um conjunto de ferramentas 
baseado em um compilador OCL que abrange vários 
módulos, os quais interpretam, verificam tipo e 
normalizam as restrições OCL. 
● OCL parser: é escrita em Java e está disponível 
livremente para a comunidade orientada a objetos, para 
encorajar o uso de OCL com modeladores UML. 
 
 
6.3 Projeto de interface 
 
Essas ferramentas de projeto o engenheiro de software a criar 
uma interface com, relativamente pouco desenvolvimento de 
software personalizado. As ferramentas fornecem acesso a 
componentes reusáveis e tornam a criação de uma interface uma 
questão selecionar dentre capacidades definidas, montadas 
usando-se a ferramenta. 
A maioria das ferramentas de desenvolvimento de interface 
com o usuário habilita um engenheiro de software a criá-la por meio 
da capacidade de “arrastar e soltar”. O desenvolvedor seleciona 
dentre várias capacidades predefinidas (construtores de formulários, 
184
mecanismos de interação, capacidade de processamento de 
comando) e coloca essas capacidades no contexto da interface a ser 
criada. Algumas dessas ferramentas são: 
● Macromedia Authorware: projetada para a criação de 
interfaces e ambientes de ensino a distância. Faz uso de 
capacidades sofisticadas de construção. 
● Motif Common Desktop Environment: é uma interface 
gráfica com o usuário integrada para sistemas abertos 
de computadores pessoais. Ela entrega uma única 
interface gráfica padronizada para a gestão de dados, 
arquivos e aplicações. 
● PowerDesigner/ PowerBuilder: é um conjunto abrangente 
de ferramentas CASE que incluem muitas capacidades 
para projetar e construir interfaces. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
185
 
Referências 
 
SOMMERVILLE, I. Engenharia de software. 8.ed. São Paulo: 
Pearson Addison-Wesley, 2007. 552 p. 
 
PRESSMAN, R. S. Engenharia de Software. São Paulo: McGraw-Hill, 
2006, 720 p. 
 
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML – Guia do usuário. 
Rio de Janeiro: Editora Campus, 2000. 472 p. 
 
KRUCHTEN, P. Introdução ao RUP – Rational Unified Process. Rio 
de Janeiro : Editora Ciência Moderna, 2003. 255p. 
 
MEDEIROS, E. Desenvolvendo software com UML 2.0. São Paulo: 
Pearson Makron Books, 2004. 264p. 
 
Rational Unified Process: Disciplinas. Fundação da Universidade 
Federal do Paraná (FUNPAR). Setembro, 2013. Disponível em: 
http://www.funpar.ufpr.br:8080/rup/process/workflow/ovu_core.htm 
 
 
186
http://www.google.com/url?q=http%3A%2F%2Fwww.funpar.ufpr.br%3A8080%2Frup%2Fprocess%2Fworkflow%2Fovu_core.htm&sa=D&sntz=1&usg=AFQjCNGuRVp3UUOJXLAQz82q1cHh-UVsKQ