Unidade 3

Prévia do material em texto

Análise de Sistemas 
 
 
Prezados (as) acadêmicos (as)! 
É com grande satisfação que iniciamos a nossa terceira unidade da 
disciplina de Requisitos, Análise e Projeto de Sistemas do curso de 
Licenciatura em Computação, que trata das características e conceitos que 
envolvem esta disciplina tão atual no cotidiano dos profissionais da 
computação. 
Nesta unidade, iremos nos concentrar em tópicos que objetivam fazer com 
que o aluno construa uma base de conhecimento que o permita realizar 
atividades voltadas à disciplina de Análise. 
Os objetivos específicos são: 
● conceituar o que é Análise de sistemas e qual sua funcionalidade; 
● identificar como utilizar modelagem UML para a análise de sistema; 
● compreender a importância da análise orientada a objetos. 
Como leitura obrigatória desta unidade, selecionamos o texto: Análise de 
Sistemas disponível na Aba “Biblioteca” e na ferramenta “Conteúdo 
Interativo”. 
Após a leitura atenta aos textos, vocês deverão realizar a atividade 
avaliativa: questionário com valor máximo: 100 pontos. 
A Leitura obrigatória é essencial para que vocês possam, de forma 
produtiva, construir o conhecimento nesta unidade, bem como participar 
das atividades avaliativas. 
Fiquem atentos ao prazo de encerramento da unidade e da atividade 
avaliativa. Se vocês tiverem alguma dúvida, não hesitem em entrar em 
contato com o seu tutor para saná-la. Além disso, procure discutir as 
temáticas apresentadas neste material com os seus colegas de curso, seja 
no ambiente de aprendizagem ou no polo de sua cidade. 
Bom trabalho! 
 
ANÁLISE DE SISTEMAS 
 
1. Introdução 
No nível técnico, a Engenharia de Software começa com uma 
séria de tarefas de modelagem que levam à especificação completa 
de requisitos e à representação abrangente do projeto para o 
software a ser construído. O modelo de análise, que consiste em 
um conjunto de modelos, pode ser considerada a primeira 
representação técnica do sistema. 
Apesar da palavra escrita ser um excelente veículo de 
comunicação, ela não é o melhor modo de representar os requisitos 
de software para computador. A análise usa uma combinação de 
formas textuais e diagramáticas para mostrar os requisitos de 
dados, função e comportamento, de modo que seja relativamente 
fácil de entender e, mais importante, mais direto de revisar quanto 
à correção, completeza e consistência. 
Mas quem realiza a análise? Um engenheiro de software 
(algumas vezes chamado de analista) constrói um modelo usando 
requisitos extraídos do cliente. E por que a análise é importante? 
Para validar os requisitos de software, é preciso examiná-los de 
diferentes pontos de vista. A modelagem da análise representa os 
requisitos em várias “dimensões”, aumentando consequentemente a 
probabilidade de que sejam encontrados erros, apareçam 
inconsistências e que omissões sejam descobertas. 
E quais são os passos para a análise? Os requisitos são 
modelados em vários formatos diagramáticos diferentes. A 
modelagem baseada em cenário representa o sistema sob o ponto 
de vista do usuário. A modelagem orientada a fluxo fornece 
indicação de como os objetos de dados são transformados pelas 
funções de processamento. A modelagem baseada em classes 
define objetos, atributos e relacionamentos. A modelagem 
comportamental mostra os estados do sistema e de suas classes, 
89
e o impacto que os eventos tem nesses estados. Uma vez criados 
os modelos preliminares, eles são refinados e analisados para 
avaliar sua clareza, completeza e consistência. O modelo final de 
análise é então validado por todos os interessados. 
 
 
2. Análise de Requisitos 
A análise de requisitos resulta da especificação das 
características operacionais do software; indica interface do 
software com outros elementos do sistema e estabelece restrições 
a que o software deve satisfazer. A análise de requisitos permite ao 
analista elaborar requisitos básicos do software estabelecidos 
durante tarefas anteriores de engenharia de requisitos e construir 
modelos que descrevam cenários de usuário, atividades funcionais, 
classes de problemas e seus relacionamentos, comportamento do 
sistema e das classes, e fluxo dos dados à medida que são 
transformados. 
A análise de requisitos fornece ao projetista de software uma 
representação da informação, função e comportamento, que podem 
ser traduzidos para os projetos arquitetural, de interfaces e em 
nível de componentes. Por fim, o modelo de análise e a 
especificação de requisitos propiciam ao desenvolvedor e ao cliente 
os meios de avaliar a qualidade quando o software é construído. 
Ao longo da modelagem de análise, o principal foco do 
engenheiro de software é em o que, e não em como. Que objetos o 
sistema manipula, que funções ele deve executar, que 
comportamentos exibe, que interfaces são definidas e que 
restrições se aplicam. 
O modelo de análise deve atingir três objetivos principais: 
1) descrever o que o cliente exige; 
2) estabelecer a base para a criação de um projeto de software; e 
3) definir um conjunto de requisitos que possam ser validados 
quando o software for construído. 
90
O modelo de análise deve existir após a descrição em nível de 
sistema (requisitos), que descreve a funcionalidade global do 
sistema como ela é conseguida pela aplicação de software, 
hardware, dados, pessoas e outros elementos do sistema; e 
anteceder o projeto de software, que descreve a arquitetura, 
interface do usuário e estrutura em nível de componente da 
aplicação de software. Esse relacionamento é apresentado na Figura 
3.1. 
 
 
 Figura 3.1 – Relacionamento entre os modelos de Requisitos, Análise e Projeto de 
Sistemas (Fonte: PRESSMAN, 2006). 
 
É importante notar que alguns elementos do modelo de 
análise estão presentes (em um nível mais alto de abstração) na 
descrição do sistema e que todos os elementos do modelo são 
diretamente rastreáveis para partes do modelo de projeto. Nem 
sempre é possível uma clara divisão das tarefas de análise e 
projeto entre essas duas importantes atividades de modelagem. 
Algum projeto invariavelmente ocorre como parte da análise e 
alguma análise será conduzida durante o projeto. 
Há algumas regras práticas que devem ser seguidas na 
criação de um modelo de análise: 
● O modelo deve focalizar os requisitos que são visíveis no 
problema ou domínio do negócio. O nível de abstração deve 
ser relativamente alto. “Não se atole em detalhes” que 
tentam explicar como o sistema funcionará. 
91
● Cada elemento do modelo de análise deve contribuir para um 
entendimento global dos requisitos de software e fornecer 
uma visão aprofundada do domínio da informação, função e 
comportamento do sistema. 
● Adie a consideração de modelos de infraestrutura e outros não 
funcionais até o projeto. Por exemplo, um banco de dados 
pode ser necessário, mas as classes necessárias para 
implementá-lo, as funções exigidas para dar acesso a ele e o 
comportamento que será exibido à medida que é usado devem 
ser considerados somente depois de a análise do domínio do 
problema ter sido completada. 
● Minimize o acoplamento ao longo de todo o sistema. É 
importante representar os relacionamentos entre classes efunções. No entanto, se o nível de “interconexão” é 
extremamente alto, esforços devem ser feitos para reduzí-lo. 
● Certifique-se de que o modelo de análise tem valor para todos 
os interessados. Cada clientela tem o seu próprio uso para o 
modelo. Por exemplo, interessados no negócio devem usar o 
modelo para validar os requisitos; projetistas devem usar o 
modelo como base para o projeto. O pessoal de Garantia de 
Qualidade (QA) deve usar o modelo para ajudar a planejar os 
testes de aceitação. 
● Mantenha o modelo tão simples quanto puder. Não acrescente 
diagramas quando eles não fornecerem informação nova. Não 
use formulários notacionais completos, quando uma lista 
simples servir. 
 
3. Conceitos de modelagem de dados 
A modelagem de análise geralmente é iniciada com a 
modelagem de dados. O engenheiro de software ou analista de 
sistemas define todos os objetos de dados processados no sistema, 
os relacionamentos entre os objetos de dados e outra informação 
pertinente aos relacionamentos. 
O objeto de dados é uma representação de quase toda 
informação composta que deve ser compreendida pelo software. Por 
informação composta queremos nos referir a algo que tem várias 
propriedades ou atributos diferentes. Assim, “largura” (um simples 
92
valor) não seria um objeto de dados válido, mas dimensões 
(incorporando altura, largura e profundidade) poderia ser definido 
como objeto. 
Um objeto de dados encapsula apenas dados – não há 
referência dentro de um objeto de dados a operações que agem 
sobre os dados. Ele pode ser representado por uma tabela, como 
mostra a Figura 3.2. Os títulos das colunas da tabela refletem os 
atributos do objeto. Neste caso, um automóvel é definido em 
termos de marca, modelo, número de placa, tipo de carroceria, cor e 
proprietário. Por exemplo, Chevy Corvette é um exemplo do objeto 
de dados automóvel. 
 
Figura 3.2 – Representação de objeto de dados (Fonte: PRESSMAN, 2006). 
 
Os atributos de dados definem as propriedades de um objeto 
de dados e podem ser usados para: a) nomear um exemplo do 
objeto de dados; b) descrever o exemplo ou; c) fazer referência a 
outro exemplo em outra tabela. Além disso, um ou mais dos 
atributos podem ser definidos como identificador, tornando-se uma 
“chave” quando desejarmos encontrar um exemplo do objeto de 
dados. Em alguns casos, valores identificadores são únicos, apesar 
disso não ser exigido. Com referência ao objeto de dados 
automóvel, um identificador razoável poderia ser o número de 
identificação. 
Objetos de dados são conectados uns aos outro de diferentes 
modos. Considere dois objetos de dados, pessoa e carro, que 
podem ser representados por meio da notação simples ilustrada na 
Figura 3.3a. Uma conexão é estabelecida entre os objetos pessoa e 
carro porque os dois são relacionados. Para estabelecermos o 
93
relacionamento, precisamos entender o papel das pessoas 
(proprietárias, neste caso) e carros, no contexto do software a ser 
construído. Podemos definir um conjunto de pares objeto/ 
relacionamento que definem os relacionamentos relevantes. Por 
exemplo: 
● Uma pessoa possui carro 
● Uma pessoa tem seguro para dirigir um carro 
Os relacionamentos possui e tem seguro para dirigir definem 
as conexões relevantes entre pessoa e carro. A figura 3.3b ilustra 
graficamente esses pares objeto/relacionamento. As setas da Figura 
3.3b fornecem informação importante sobre a direcionalidade do 
relacionamento e frequentemente reduzem ambigüidade ou má 
interpretação. 
 
(a) 
 
 
(b) 
 
Figura 3.3 – Relacionamentos entre objetos de dados (Fonte: PRESSMAN, 
2006). 
 
Os elementos da modelagem de dados – objetos, atributos e 
relacionamentos – fornecem a base para a compreensão do domínio 
de informação de um problema. No entanto, também deve ser 
entendida a informação adicional relacionada a esses elementos 
básicos. O modelo de dados deve ser capaz de representar o 
número de ocorrências dos objetos em um dado relacionamento. 
Outro tópico importante é a cardinalidade. A cardinalidade é a 
94
especificação do número de ocorrências de um objeto que pode ser 
relacionado ao número de ocorrências de outro objeto. Por exemplo, 
um objeto pode se relacionar somente com um outro objeto 
(relacionamento 1: 1), um objeto pode se relacionar com muitos 
objetos (um relacionamento 1: N); um certo número de ocorrências 
de um objeto pode se relacionar com um outro número de 
ocorrências de um outro objeto (relacionamento m: n). 
A modalidade de uma relação é 0 se não houver necessidade 
explícita de o relacionamento ocorrer ou se o relacionamento for 
opcional. A modalidade é 1 se a ocorrência do relacionamento for 
obrigatória. 
 
4. Abordagens de modelagem de análise 
 
Uma visão de modelagem de análise, chamada de análise 
estruturada, considera os dados e os processos que transformam 
os dados em entidades separadas. Objetos de dados são 
modelados para que definam seus atributos e relacionamentos. 
Processos que manipulam objetos de dados são modelados para 
que mostrem como eles transformam os dados à medida que os 
objetos de dados fluem pelo sistema. A modelagem orientada a 
fluxo de dados é uma das notações de análise estruturada mais 
conhecidas e será abordada na próxima seção. 
Uma segunda abordagem para modelagem de análise, chamada 
de análise orientada a objetos, focaliza a definição de classes e o 
modo pelo qual elas colaboram umas com as outras para atender 
aos requisitos do cliente. A UML e o Processo Unificado são 
predominantemente orientados a objetos. A análise orientada a 
objetos é composta por várias notações de modelagem e será 
abordada de forma mais enfática neste curso. 
95
Equipes de desenvolvimento de software frequentemente 
escolhem uma abordagem e excluem todas as representações da 
outra. A questão não é definir qual é a melhor, mas que combinação 
de representações fornecerá aos interessados o melhor modelo de 
requisitos de software e a conexão mais efetiva para o projeto de 
software. 
 
3.1 Análise Estruturada com modelagem orientada a fluxo 
 
A modelagem orientada a fluxo de dados continua a ser uma 
das notações de Análise Estruturada mais amplamente utilizadas 
atualmente. Embora o Diagrama de Fluxo de Dados (DFD) e demais 
diagramas e informações relacionadas não sejam parte formal da 
UML, eles podem ser utilizados para complementar os diagramas 
UML e fornecer visão adicional dos requisitos e fluxo do sistema. 
O DFD tem uma visão entrada-processo-saída de um sistema. 
Ou seja, objetos de dados entram no software, são transformados 
por elementos de processamento e os objetos de dados resultantes 
saem do software. Objetos de dados são representados por setas 
rotuladas e transformações são representadas por círculos (também 
chamados de bolhas). O DFD é apresentado de modo hierárquico, 
isto é, o primeiro modelo de fluxo de dados (algumas vezes 
chamado de DFD nível 0 ou diagrama de contexto) representa o 
sistema como um todo. Diagramas de Fluxo de Dados subsequentes 
refinam o diagrama de contexto, fornecendo detalhamentoprogressivo em cada nível subsequente. 
Algumas diretrizes simples podem ajudar durante a derivação 
do diagrama de fluxo de dados: 
● O diagrama de fluxo de dados nível 0 deve mostrar o 
software/sistema como uma única bolha; 
96
● A entrada e a saída principal devem ser cuidadosamente 
registradas; 
● O refinamento deve começar pelo isolamento dos 
processos, objetos de dados e depósitos de dados 
candidatos a ser representados no nível seguinte; 
● Todas as setas e bolhas devem ser rotuladas com 
bolhas significativas; 
● A continuidade do fluxo de informação deve ser mantida 
de nível para nível; e 
● Uma bolha de cada vez deve ser refinada. Há uma 
tendência natural do analista de tornar complexo o 
diagrama de fluxo de dados. Isso ocorre quando ele 
tenta detalhar em excesso ou representar aspectos 
procedurais do software ao invés do fluxo da informação. 
 
As figuras 3.4a, 3.4b e 3.4c ilustram DFDs em diferentes níveis 
de refinamento. 
 
 
(a) 
 
 
97
 
(b) 
 
 
(c) 
Figura 3.4 – Diagrama de Fluxo de Dados em diferentes níveis de refinamento 
(Fonte: PRESSMAN, 2006). 
 
3.2 Análise orientada a objetos 
 
Qualquer discussão sobre análise orientada a objetos deve 
98
começar focalizando o termo orientado a objetos. O que é um ponto 
de vista orientado a objetos? Por que um método é considerado 
orientado a objetos? O que é um objeto? À medida que a orientação 
a objetos ganhou inúmeros adeptos durante as décadas de 1980 e 
1990, têm havido muitas opiniões diferentes sobre as respostas 
corretas a essas questões. Hoje, uma visão coerente de orientação 
a objeto emergiu. O objetivo da orientação a objetos é definir todas 
as classes relevantes ao problema a ser resolvido – as operações e 
os atributos associados a elas, as relações entre elas e o 
comportamento que elas exibem. Para tanto, algumas tarefas 
devem ser realizadas: 
1) Os requisitos básicos do usuário precisam ser discutidos entre 
o cliente e o engenheiro de software; 
2) As classes precisam ser identificadas (ou seja, atributos e 
métodos são definidos); 
3) Uma hierarquia de classes precisa ser especificada; 
4) As relações de objetos para objeto (conexões entre objetos) 
devem ser representadas; 
5) O comportamento do objeto precisa ser modelado; 
6) As tarefas de 1 a 5 são replicadas iterativamente até que o 
modelo seja completado. 
 
Ao invés de examinar o problema usando um modelo mais 
convencional de entrada-processamento-saída (fluxo de informação) 
ou um modelo derivado exclusivamente de estruturas de informação 
hierárquicas, a Análise Orientada a Objetos (AOO) cria um modelo 
orientado a classes que se apoia no entendimento dos conceitos de 
orientação a objetos. 
 
3.2.1 Conceitos orientados a objetos 
99
Os conceitos relacionados a orientação a objetos tornaram-se 
bem estabelecidos no mundo da engenharia de software. A seguir 
são apresentadas descrições resumidas de conceitos importantes, 
frequentemente encontrados durante a modelagem de análise. 
 
● Atributos: uma coleção de valores de dados que 
descrevem uma classe. 
● Classe: encapsula dados e abstrações procedurais 
necessárias para descrever o conteúdo e o 
comportamento de alguma entidade do mundo real. Dito 
de outro modo, classe é uma descrição generalizada (por 
exemplo, um gabarito, padrão ou planta) que descreve 
uma coleção de objetos semelhantes. 
● Objetos: instâncias de uma classe específica. Objetos 
herdam os atributos e operações da classe. 
● Operações: também chamadas de métodos e serviços, 
fornecem uma representação de um dos 
comportamentos da classe. 
● Subclasse: especialização da superclasse. Uma 
subclasse pode herdar tanto atributos quanto operações 
de uma superclasse. 
● Superclasse: também chamada de classe-base, é uma 
generalização de um conjunto de classes relacionadas a 
ela. 
 
Para onde vamos quando o assunto é desenvolvimento de 
elementos baseados em classe de um modelo de análise – classes, 
objetos, atributos, operações, pacotes, modelos CRC e diagramas 
de colaboração? Serão apresentados à seguir uma série de 
diretrizes informais que vão ajudar na identificação e representação. 
100
 
3.2.2 Identificação de classes de análise 
 
Podemos começar a identificar classes examinando o enunciado 
do problema ou executando uma “análise gramatical” das narrativas 
de casos de uso ou de processamento do sistema desenvolvidas 
para o sistema a ser construído. As classes são determinadas 
sublinhando-se cada substantivo ou cláusula substantiva e 
colocando-as em uma tabela simples. Sinônimos devem ser 
anotados. Se a classe é necessária para implementar uma solução, 
então ela é parte do espaço de solução, caso contrário, se uma 
classe é necessária apenas para descrever uma solução, ela é parte 
do espaço do problema. 
 
3.2.3 Especificação de atributos 
 
Os atributos descrevem uma classe que foi selecionada para 
inclusão no modelo de análise. Em essência, são os atributos que 
definem a classe – que esclarecem o que a classe representa no 
contexto do espaço do problema. Para desenvolver um conjunto de 
atributos significativos para uma classe de análise, um engenheiro 
de software pode novamente estudar o caso de uso e selecionar as 
“coisas” que razoavelmente “pertencem” à classe. Além disso, a 
seguinte questão deve ser respondida para cada classe: “Que itens 
de dados (compostos e/ou elementares) descrevem plenamente 
essa classe no contexto do problema em mãos?”. 
 
3.2.4 Definição das operações 
 
As operações definem o comportamento de um objeto. Apesar 
101
de existirem muitos tipos diferentes de operação, elas podem ser 
divididas em geral em quatro amplas categorias: 
1) operações que de algum modo manipulam dados (somar, 
excluir, reformatar, selecionar); 
2) operações que realizam um cálculo; 
3) operações que pesquisam o estado de um objeto; e 
4) operações que monitoram um objeto quanto à ocorrência de 
um evento de controle. 
 
Essas funções são realizadas pela operação sobre os atributos 
e/ou associações. Assim sendo, uma operação deve ter 
“conhecimento” da natureza dos atributos e associações da classe. 
Como primeira iteração para derivar um conjunto de operações 
para uma classe de análise, o analista pode novamente estudar a 
narrativa de processamento (ou caso de uso) e selecionar aquelas 
operações que razoavelmente pertencem à classe. Para conseguir 
isso, a análise gramatical é novamente estudada e os verbos são 
isolados. Alguns desses verbos serão operações legítimas e podem 
ser facilmente conectados a uma classe específica. A Figura 3.5 
ilustra um diagrama da classe “PlantaBaixa” que exemplifica o uso 
de operações. 
102
 
 Figura 3.5 – Diagrama de Classes com as respectivas operações (Fonte: 
PRESSMAN, 2006). 
 
3.2.5 Modelagem Classe-Responsabilidade-Colaboração (CRC) 
 
A modelagem classe-responsabilidade-colaboração fornece um 
meio simples para identificar e organizar as classes relevantes aos 
requisitos do sistema ou produto. Um modelo CRC é na realidade 
uma coleção de cartões-padrão de indexação que representam as 
classes. Os cartões são divididos em três seções: no alto do cartãoo nome da classe é descrito, no corpo são listadas as 
responsabilidades da classe à esquerda e os colaboradores à 
direita. 
O modelo CRC pode fazer uso de cartões de indexação reais ou 
virtuais. O objetivo é desenvolver uma representação organizada de 
103
classes. Responsabilidades são os atributos e operações relevantes 
à classe. Dito simplesmente, uma responsabilidade é “qualquer 
coisa que a classe sabe ou faz”. Colaboradores são as classes 
necessárias para dar à classe a informação necessária para 
completar uma responsabilidade. Em geral, uma colaboração implica 
tanto solicitação de informação como solicitação de alguma ação. A 
Figura 3.6 ilustra um cartão CRC simples para a classe 
“PlantaBaixa”. 
 
 
Figura 3.6 – Modelo de Cartão CRC (Fonte: PRESSMAN, 2006). 
 
3.2.6 Associações e dependências 
 
Em muitas instâncias, duas classes de análise estão 
relacionadas entre si de algum modo, como dois objetos de dados 
podem estar relacionados entre si. Em UML esses relacionamentos 
são chamados de associações. Em alguns casos, uma associação 
pode ser melhor definida pela indicação da multiplicidade. Nas 
restrições de multiplicidade, ilustradas na Figura 3.7, “um ou mais” 
é representado usando 1...0 e “0 ou mais” por 0..*. Em UML, o 
asterisco indica um extremo superior não limitado para o intervalo. 
 
104
 
Figura 3.7 – Restrições de multiplicidade (Fonte: PRESSMAN, 2006). 
 
Em muitas instâncias, existe um relacionamento 
cliente-servidor entre duas classes de análise. Em tais casos, uma 
classe-cliente depende da classe-servidor de algum modo, e um 
relacionamento de dependência é estabelecido. Dependências são 
definidas por um estereótipo. Como já vimos na Unidade 2, o 
estereótipo é um mecanismo de “extensabilidade” na UML que 
permite a um engenheiro de software definir um elemento especial 
de modelagem cujas semânticas são definidas pelo cliente. Em 
UML, estereótipos são representados por sinais duplos de maior e 
menor (<<estereótipo>>) 
 
3.2.7 Criação de um modelo comportamental 
 
Diagramas de classe, cartões indexados CRC e outros modelos 
orientados à classe representam elementos estáticos do modelo de 
análise. Chegou a hora de fazer uma transição para o 
comportamento dinâmico do sistema ou produto. Para tanto, 
precisamos representar o comportamento do sistema como uma 
função de eventos e tempos específicos. 
105
O modelo comportamental indica como o software responderá a 
eventos ou estímulos externos. Para criar um modelo, o analista 
precisa executar os seguintes passos: 
1) Avaliar todos os casos de uso para entender plenamente a 
sequência de interação dentro do sistema. 
2) Identificar os eventos que dirigem a sequência de interação e 
entender como esses eventos se relacionam a classes específicas. 
3) Criar uma sequência para cada caso de uso. 
4) Construir um diagrama de estados para o sistema. 
5) Revisar o modelo comportamental para verificar a precisão e 
a consistência. 
 
Como já vimos na Unidade 2, o caso de uso representa uma 
sequência de atividades que envolve atores e o sistema. Em geral, 
um evento ocorre sempre que um sistema e um ator trocam 
informação, lembrando que um evento não é a informação que foi 
trocada, mas o fato de que a informação foi trocada. Um caso de 
uso é examinado para encontrar pontos de troca de informação. 
As partes sublinhadas do cenário de caso de uso indicam 
eventos. Um ator deve ser identificado para cada evento; a 
informação que é trocada deve ser registrada e quaisquer condições 
ou restrições devem ser listadas. Uma vez identificados todos os 
eventos, eles são associados aos objetos envolvidos. Objetos 
podem ser responsáveis pela geração de eventos ou pelo 
reconhecimento de eventos que ocorreram em outro lugar. 
O sistema tem estados que representam comportamentos 
específicos externamente observáveis. Uma classe tem estados que 
representam seu comportamento à medida que o sistema realiza 
suas funções. No contexto de modelagem comportamental, devem 
ser consideradas duas caracterizações de estados diferentes: 
106
 
1) o estado de cada classe, à medida que o sistema realiza sua 
função; e 
2) o estado do sistema, observando de fora, à medida que o 
sistema realiza sua função. 
 
O estado de um objeto pode apresentar características 
passivas e ativas. Um estado passivo é simplesmente o estado 
atual de todos os atributos de um objeto. O estado ativo de um 
objeto indica o estado atual do objeto à medida que ele passa por 
uma transformação ou processamento contínuo. Um evento precisa 
ocorrer para forçar o objeto a realizar a transição de um estado para 
outro. Algumas representações estáticas e comportamentais 
referentes à atividade/ modelagem de análise serão discutidas na 
seção 6. 
 
5. Modelagem de análise utilizando o RUP 
O propósito da análise orientada ao RUP é transformar os 
requisitos do sistema numa forma que mapeie a área do projetista 
do software de interesse – quer dizer, para um conjunto de classes 
e subsistemas. Esta transformação é dirigida pelos casos de uso e 
amoldada mais adiante pelos requisitos não funcionais do sistema. 
A análise focaliza-se em assegurar que os requisitos funcionais do 
sistema sejam controlados. Por causa da simplicidade, ignora 
muitos dos requisitos não funcionais do sistema e também as 
restrições do ambiente de implementação. Como resultado, a 
análise expressa uma imagem do sistema “quase ideal”. 
 
5.1 Atividades 
 
107
As atividades relacionadas à análise e projeto são 
consideradas pelo RUP como uma disciplina única, conforme vimos 
na Unidade 1. No entanto, neste curso, apesar das atividades de 
Requisitos, Análise e Projeto de Sistemas estarem 
inter-relacionadas, elas são tratadas separadamente para fins 
didáticos. A Figura 3.8 ilustra o fluxo de atividades relacionadas à 
Análise e Projeto, cuja abordagem será feita separadamente nesta 
Unidade 3 e na Unidade 4. 
 
Figura 3.8 – Fluxo de Atividades de Análise,em destaque (Fonte: adaptado de 
www.funpar.ufpr.br). 
 
● Definir uma sugestão de arquitetura: Este detalhe de fluxo é 
composto das atividades de análise arquitetônica e de análise 
de caso de uso. Seu propósito é: 
➢ Criar um esboço inicial da arquitetura do sistema, 
definindo: a) um conjunto inicial de elementos 
arquiteturais significantes para ser usado como base 
108
para a análise; b) Um conjunto inicial de mecanismos de 
análise; c) a formação de camadas e organização inicial 
do sistema; e d) as realizações de caso de uso para ser 
endereçado na iteração atual. 
➢ Identificar as classes de análise dos casos de uso 
arquiteturalmente significantes. 
➢ Atualizar as realizações de caso de uso com as 
interações de classe de análise. 
 
● Analisar comportamento: este detalhe do fluxo é composto 
das atividades análise de caso de uso, identificar elementos 
do projeto e revisão do projeto. O propósito deste detalhe do 
fluxo é transformar as descrições de comportamento 
fornecidas pelos casos de uso num conjunto de elementos nos 
quais o projeto possa ser baseado. Observe que, em analisaro comportamento, estamos nos tornando menos interessados 
nos requisitos não funcionais impostos no sistema e muito 
mais na forma como entregar as capacidades necessárias da 
aplicação. 
 
5.2 Papéis 
 
No contexto que abrange as atividades de Análise, entendemos 
que somente o Arquiteto de Software possui funções a 
desempenhar. O Arquiteto de Software conduz e coordena as 
atividades técnicas e artefatos ao longo do projeto, como ilustrado 
na Figura 3.9. Ele estabelece a estrutura global para cada visão 
arquitetônica: a decomposição da visão, o agrupamento de 
elementos e as interfaces entre os agrupamentos principais. Em 
contraste com as visões dos outros papéis, a visão do arquiteto é 
109
de amplitude e não de profundidade. 
 
 
Figura 3.9 – Papel e artefatos da Análise (Fonte: www.funpar.ufpr.br). 
 
 
5.3 Artefatos 
 
● Prova de Conceito Arquitetural: é uma solução, que pode 
simplesmente ser conceitual, para os requisitos significativos 
arquiteturalmente que são identificados primeiro na Iniciação. 
● Modelo de Implantação: mostra a configuração dos nós de 
processamento em tempo de execução e os vínculos de 
comunicação entre eles, assim como os objetos e as 
instâncias de componentes que neles residem. 
● Documento de Arquitetura de Software: fornece uma visão 
geral de arquitetura abrangente do sistema, usando diversas 
visões de arquitetura para descrever diferentes aspectos do 
sistema. 
● Modelo de Análise: Geralmente há um modelo de projeto do 
sistema; a análise produz um esboço grosseiro do sistema 
que mais adiante será refinado no projeto. As camadas 
superiores deste modelo descrevem os aspectos da própria 
aplicação, ou mais orientados à análise do sistema. Usar um 
único modelo reduz o número de artefatos que devem ser 
110
mantidos em estado consistente. O modelo de análise é uma 
abstração ou generalização do projeto e em algumas 
organizações o modelo de análise separado do projeto tem 
provado ser útil. Ele omite a maioria dos detalhes de como o 
sistema funciona e fornece uma avaliação da funcionalidade 
do sistema. O trabalho extra requerido para assegurar que os 
modelos de análise e projeto permaneçam consistentes deve 
ser equilibrado em relação ao benefício de ter uma visão do 
sistema que represente apenas seus detalhes de 
funcionamento mais importantes. 
● Modelo de Projeto: o artefato primário da análise e do fluxo 
de projeto é o modelo de projeto. Consiste em um conjunto 
de colaborações de elementos do modelo que fornecem o 
comportamento do sistema. Em troca, este comportamento é 
derivado principalmente do modelo de caso de uso e 
requisitos não funcionais. O modelo de projeto consiste em 
colaborações de classes que podem ser agregadas em pacotes 
e subsistemas para ajudar a organizar o modelo e fornecer 
blocos compostos da construção dentro do modelo. 
● Arquitetura de Referência: é, basicamente, um padrão ou 
conjunto de padrões de arquitetura predefinido, possivelmente 
parcial ou totalmente instanciado, projetado e testado em 
determinados contextos de negócios e técnicos com artefatos 
de suporte que permitam seu uso. Geralmente, esses 
artefatos são resultantes de projetos anteriores. 
● Interface: as interfaces são utilizadas para especificar o 
comportamento oferecido por classes, subsistemas e 
componentes de um modo independente da implementação do 
comportamento. Eles especificam um conjunto de operações 
executado pelos elementos do modelo, inclusive o tipo e 
111
número retornado e os tipos de parâmetros. Qualquer dos dois 
elementos do modelo que oferece a mesma interface é 
substituível. As interfaces melhoram a flexibilidade dos 
projetos, reduzindo dependências entre as partes do sistema 
e os tornando mais fáceis de mudar. 
 
Artefatos para sistemas em tempo real 
 
Os sistemas em tempo real são aqueles com requisitos 
particulares para pontualidade ou responsabilidade, geralmente com 
a restrição de prazos finais. Tais sistemas não frequentemente 
encontrados em aplicações de segurança crítica. O RUP descreve os 
seguintes artefatos adicionais, de análise especificamente, 
planejados para satisfazer as demandas do desenvolvimento de tais 
sistemas: 
● Sinal: um sinal é um evento assíncrono que pode causar uma 
transição de estado na máquina de estado de um objeto. 
● Evento: um evento é a especificação de uma ocorrência em 
espaço e tempo ou, menos formalmente, uma ocorrência de 
alguma coisa à qual o sistema tem que responder. 
● Protocolo: um protocolo especifica o modo com um conjunto 
de portas se comunica, as mensagens trocadas e como são 
ordenadas. 
 
6. Modelagem de análise utilizando diagramas 
UML 
 
Quando identificamos quem realizará um Caso de Uso ou um 
de seus cenários principais em termos de classes na forma 
112
conceitual, começamos a direcionar nossa atenção ao workflow de 
análise 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 análise por meio da UML, nosso foco 
está nos diagramas de classes, objetos, gráfico de estados e 
seqüência. 
 
 
6.1 Diagrama de classes 
 
Os diagramas de classes são os diagramas encontrados com 
maior freqüência na modelagem de sistemas orientados a objetos e 
são compostos de um conjunto de classes, interfaces, colaborações 
e seus relacionamentos. Os diagramas de classes são a base para 
um par de diagramas relacionados: os diagramas de componentes e 
diagramas de implantação, abordados na Unidade 4. Na UML o 
diagrama de classes pode ser utilizado para a visualização de 
aspectos estáticos da construção de software e especificação dos 
detalhes da construção, conforme ilustrado na Figura 3.10. 
 
113
 
Figura 3.10 – Diagrama de Classes (Fonte: BOOCH et. al.,2000). 
 
Os diagramas de classes costuma conter os seguintes itens: 
● Classes 
● Interfaces 
● Colaborações 
● Relacionamentos de dependência, generalização e 
associação. 
 
Na modelagem da visão estática de um sistema podemos 
utilizar três formas diferentes de diagramas de classes: modelagem 
do vocabulário do sistema, modelagem de colaboração simples e 
modelagem do esquema lógico de um banco de dados. 
 
6.1.1 Modelagem do vocabulário do sistema 
 
114
Geralmente utilizamos as classes para fazermos a modelagem 
de abstrações definidas a partir do problema que estamos tentando 
solucionar ou a partir da tecnologia empregada para implementar 
uma solução para esse problema. Cada uma dessas abstrações é 
uma parte do vocabulário do sistema, que, em conjunto, representa 
as coisas importantes para os usuários e implementadores. 
Técnicas como os cartões CRC e a análise baseada em casos 
de uso são formas excelentes para auxiliar os usuários a descobrir 
essas abstrações. Para os implementadores, as abstrações 
geralmente são os itens disponíveis na tecnologia que constituem 
partes da solução. A Figura 3.11 ilustra um conjunto de classes 
definidas a partir de um sistema de vendas de varejo.Figura 3.11 - Modelagem do vocabulário de um sistema (Fonte: BOOCH et. 
al.,2000). 
 
6.1.2 Modelagem de colaboração simples 
115
 
Uma colaboração é uma sociedade de classes, interfaces e 
outros elementos que funcionam em conjunto para proporcionar 
algum comportamento cooperativo, maior do que a soma de todos 
os elementos. Além de captar o vocabulário do sistema, é preciso 
prestar atenção para visualizar, especificar, construir e documentar 
as várias formas em que esses itens trabalham em conjunto em seu 
vocabulário. Use os diagramas de classes para visualizar e 
especificar o conjunto de classes e seus relacionamentos. A Figura 
3.12 mostra um conjunto de classes estabelecido a partir da 
implementação de um robô autônomo. 
 
Figura 3.12 - Modelagem de colaboração simples (Fonte: BOOCH et. al.,2000). 
 
6.1.3 Modelagem do esquema lógico de um banco de dados 
 
Em muitos domínios faz-se necessária a armazenagem de 
informações persistentes em um banco de dados relacional, em um 
116
banco de dados orientado a objetos ou em um banco de dados 
híbrido. Neste caso os objetos persistentes poderão ser 
armazenados em um banco de dados para serem recuperados 
posteriormente. A UML é adequada para a modelagem de esquemas 
lógicos de bancos de dados, além dos próprios bancos de dados 
físicos. A Figura 3.13 mostra um conjunto de classes definido a 
partir de um sistema de informações para uma escola. 
 
Figura 3.13 - Modelagem de um esquema (Fonte: BOOCH et. al.,2000). 
 
6.1.4 Recomendações para diagramação de Classes 
 
Um diagrama de classes bem estruturado: 
● Tem como foco comunicar um único aspecto da visão estática 
do projeto do sistema. 
● Contém somente elementos essenciais à compreensão desse 
aspecto. 
● Fornece detalhes consistentes com o respectivo nível de 
abstração, exibindo somente os adornos essenciais à 
117
compreensão. 
● Não é tão minimalista que prejudique a informação do leitor 
sobre a semântica importante. 
 
Ao criar um diagrama de classes: 
● Atribua-lhe um nome que comunique seu propósito. 
● Distribua seus elementos de modo a minimizar o 
cruzamento de linhas. 
● Organize especialmente seus elementos de modo que os 
itens semanticamente relacionados fiquem fisicamente 
próximos. 
● Use notas e cores como indicações visuais com a 
finalidade de chamar a atenção para características 
importantes do diagrama. 
● Procure não exibir uma quantidade excessiva de tipos de 
relacionamentos. Em geral, um único tipo de 
relacionamento tenderá a predominar em cada diagrama 
de classes. 
 
6.2 Diagrama de objetos 
 
Os diagramas de objetos fazem a modelagem de instâncias de 
itens contidos em diagramas de classes e ilustram um conjunto de 
objetos e seus relacionamentos em determinado ponto no tempo. 
São utilizados para fazer a modelagem da visão estática do projeto 
ou do processo de um sistema, ou seja, resultam em um retrato do 
sistema em determinado momento contendo um conjunto de 
objetos, seus estados e relacionamentos. Graficamente, o diagrama 
de objetos é uma coleção de vértices e de arcos, conforme ilustrado 
na Figura 3.14. 
118
 
Figura 3.14 – Diagrama de objetos (Fonte: BOOCH et. al.,2000). 
 
Os diagramas de objetos costumam conter objetos e vínculos. 
Assemelham-se ao diagrama de classes no que tange à modelagem 
da visão de projeto estático ou da visão do processo estático de um 
sistema. No entanto, no diagrama de objetos a modelagem é feita 
a partir da perspectiva de instâncias reais ou prototípicas. Essa 
visão atende principalmente aos requisitos funcionais do sistema – 
ou seja, os serviços que o sistema deverá proporcionar aos seus 
usuários finais. Geralmente o diagrama de objetos é utilizado de 
uma única maneira, por meio da modelagem de estrutura dos 
objetos. 
Ao construir um diagrama de classes, de componentes ou de 
implantação, é captado um conjunto de abstrações que expõe a 
semântica e os relacionamentos com outras abstrações, mostrando 
somente a potencialidade. 
Congelando o sistema em execução ou apenas imaginando um 
momento no tempo em um sistema modelado, um conjunto de 
objetos será encontrado, cada um em um estado específico e em 
um determinado relacionamento com os demais objetos. 
119
Com os diagramas de objetos não é possível especificar 
completamente a estrutura de objetos de um sistema, pois para 
uma classe individual poderá haver várias instâncias e, para um 
conjunto de classes em relacionamentos um-para-um, muitas vezes 
poderá haver mais configurações possíveis desses objetos. Ao 
utilizar diagramas de objetos torna-se possível expor 
significativamente somente conjuntos interessantes de objetos 
concretos ou prototípicos. Isso é o que significa fazer a modelagem 
de uma estrutura de objetos – um diagrama de objetos exibe um 
único conjunto de objetos relacionados uns com os outros em um 
determinado momento. A Figura 3.15 ilustra um conjunto de objetos 
definidos a partir da implementação de um robô autônomo. 
 
Figura 3.15 – Modelagem de estruturas de objetos (Fonte: BOOCH et. 
al.,2000). 
 
6.2.1 Recomendações para diagramação de Objetos 
 
Um diagrama de objetos bem estruturado: 
● Tem seu foco voltado para comunicar um único aspecto 
da visão estática, de projeto ou de processo, do 
120
sistema. 
● Representa um único quadro no enredo dinâmico 
representado por um diagrama de interação. 
● Contém somente aqueles elementos essenciais para a 
compreensão desse aspecto. 
● Fornece detalhes consistentes com seu nível de 
abstração; você deverá expor apenas os valores de 
atributo e outros adornos que sejam essenciais para a 
compreensão. 
● Não é tão minimalista, que acabe informando mal o 
leitor sobre a semântica que seja importante. 
 
Na definição de um diagrama de objetos, deve-se: 
● Dar-lhe um nome capaz de comunicar seu propósito. 
● Distribuir seus elementos para minimizar a ocorrência de 
linhas cruzadas. 
● Organizar seus elementos espacialmente, para que os 
itens semanticamente afins apareçam fisicamente 
próximos. 
● Utilizar notações e cores como indicações visuais para 
chamar a atenção em relação a características 
importantes de seu diagrama. 
● Incluir os valores, o estado e o papel de cada objeto, 
conforme seja necessário para comunicar suas 
intenções. 
 
6.3 Diagrama de gráficos de estados 
 
Um diagrama gráfico de estados mostra uma máquina de 
estados, dando ênfase ao fluxo de controle de um estado para 
121
outro. Uma máquina de estados é um comportamento que 
especifica as sequências de estados pelos quais um objeto passa 
durante seu tempo de vida em resposta a eventos, juntamente com 
suas respostas a esses eventos. 
Um estado é uma condição ou situação na vida de um objeto 
durante a qual ele satisfaz alguma condição, realiza alguma 
atividade ou aguarda algum evento. Um evento é a especificação de 
uma ocorrência significativa que tem uma localização no tempo e no 
espaço. No contexto de uma máquina de estados, um evento é a 
ocorrência de um estímulo capaz de ativar uma transição de estado. 
Uma transição é um relacionamento entre dois estados, indicando 
que um objetono primeiro estado realizará certas ações e entrará 
no segundo estado quando um evento especificado ocorrer e 
condições especificadas estão satisfeitas. Uma atividade é uma 
execução não atômica em andamento em uma máquina de estados. 
Uma ação é uma computação atômica executável que resulta na 
alteração do estado do modelo ou no retorno de um valor. 
Graficamente, um diagrama de estados é uma coleção de vértices e 
arcos. 
As máquinas de estados são empregadas para a modelagem 
dos aspectos dinâmicos de um sistema. Uma máquina de estados 
pode ser visualizada de duas maneiras: dando-se ênfase ao fluxo 
de controle de uma atividade para outra (utilizando diagramas de 
atividades) ou dando-se ênfase aos estados potenciais dos objetos 
e às transições entre esses estados (utilizando diagramas de 
gráficos de estados). Máquinas de estados bem estruturadas são 
como algoritmos bem estruturados: são eficientes, simples, 
adaptáveis e compreensíveis. 
Na UML, a modelagem de comportamentos ordenados por 
eventos de um objeto é feita pela utilização de diagramas de 
122
gráficos de estados. Conforme mostra a Figura 3.16, um diagrama 
de gráfico de estados é simplesmente a apresentação de uma 
máquina de estados, dando ênfase ao fluxo de controle de um 
estado para outro. 
 
Figura 3.16 – Diagrama de gráfico de estados (Fonte: BOOCH et. al., 2000). 
 
Os diagramas de gráficos de estados costumam conter: 
● Estados simples e estados compostos 
● Transições, incluindo eventos e ações 
 
6.3.1 Recomendações para diagramação de Estados 
 
Um diagrama de gráficos de estados bem estruturado: 
● Tem como foco a comunicação de um aspecto da 
dinâmica de um sistema. 
● Contém somente os elementos essenciais à 
compreensão desse aspecto. 
● Fornece detalhes consistentes com seu nível de 
abstração (expõe somente as características essenciais 
à compreensão) 
 
123
Ao definir um diagrama de gráficos de estados: 
● Dê-lhe um nome capaz de comunicar seu propósito 
● Inicie com a modelagem dos estados estáveis do objeto 
e depois prossiga com a modelagem das transições 
legais de um estado para outro. Inclua ramificação, 
concorrência e fluxo de objetos como considerações 
secundárias, possivelmente em diagramas separados. 
● Distribua seus elementos de forma a minimizar o 
cruzamento de linhas. 
 
6.4 Diagrama de sequência 
 
Um diagrama de sequências é um diagrama de interação que 
dá ênfase à ordenação temporal de mensagens. Conforme ilustra a 
Figura 3.17, um diagrama de sequências é formado se colocando 
primeiro os objetos que participam da interação no nível superior do 
diagrama, ao longo do eixo X. Tipicamente, o objeto que inicia a 
interação é colocado à esquerda e objetos mais subordinados vão 
crescendo à direita. A seguir, as mensagens que esses objetos 
enviam e recebem são colocadas ao longo do eixo Y, em ordem 
crescente do tempo, de cima para baixo. Isso proporciona ao leitor 
uma clara indicação visual do fluxo de controle ao longo do tempo. 
124
 
Figura 3.17 – Diagrama de sequências (Fonte: BOOCH et. al., 2000). 
 
Os diagramas de sequências têm duas características que os 
diferenciam dos diagramas de colaboração. Primeiro, existe linha 
de vida do objeto. A linha de vida do objeto é a linha tracejada 
vertical que representa a existência de um objeto em um período de 
tempo. Muitos objetos que aparecem em um diagrama de interação 
terão existência igual à duração da interação; assim, esses objetos 
são alinhados na parte superior do diagrama, com suas linhas de 
vida desenhadas de cima para baixo no diagrama. Objetos poderão 
ser criados durante a interação. Suas linhas de vida se iniciam com 
o destinatário de mensagem estereotipado como destroy (e são 
fornecidas as indicações visuais de um grande X, marcando o fim de 
suas vidas). 
Segundo, existe o foco de controle. O foco de controle é um 
retângulo alto e estreito, que mostra o período durante o qual um 
objeto está desempenhando uma ação, diretamente ou por meio de 
um procedimento subordinado. A parte superior do retângulo é 
alinhada com o início da ação; a parte inferior é alinhada com sua 
conclusão (e pode ser marcada por uma mensagem de retorno). 
125
Você pode exibir o aninhamento de um foco de controle (causado 
por recursão, uma chamada a uma auto-operação ou pela chamada 
feita por outro objeto) mantendo um outro foco de controle 
ligeiramente à direita de seu foco pai (e pode fazer isso em uma 
profundidade arbitrária). Para ser especialmente preciso em relação 
ao local em que se encontra o foco de controle, você também pode 
sombrear a região do retângulo durante a qual o método do objeto 
está realmente sendo computado (sem que o controle tenha sido 
passado a outro objeto). 
Os diagramas de sequências costumam conter: 
● Objetos 
● Vínculos 
● Mensagens 
 
6.4.1 Recomendações para diagramação de Sequências. Um 
diagrama de sequências bem estruturado... 
● 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 sequências: 
● 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. 
126
● 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. 
 
7. Ferramentas para modelagem de análise 
 
7.1 Modelagem de dados 
As ferramentas de modelagem de dados fornecem ao 
engenheiro de software habilidade para representar objetos de 
dados, suas características e seus relacionamentos. Usadas 
principalmente para aplicações de grandes nacos de dados e outros 
projetos de sistemas de informação, as ferramentas de modelagem 
de dados fornecem um meio automatizado para criação de 
diagramas entidade/ relacionamento abrangentes, dicionários de 
objetos de dados e modelos relacionados. 
As ferramentas dessa categoria possibilitam ao usuário 
descrever objetos de dados e seus relacionamentos. Em alguns 
casos, as ferramentas usam a notação Diagrama Entidade/ 
Relacionamento (DER). Em outros, as ferramentas modelam 
relacionamentos por meio de alguns outros mecanismos. 
Ferramentas dessa categoria possibilitam a criação de um modelo 
de banco de dados pela geração do esquema de banco de dados 
comum para Sistemas Gerenciadores de Banco de Dados (SGBD). 
As ferramentas listadas abaixo não representam uma 
recomendação e sim uma exemplificação de ferramentas dessa 
categoria de modelagem: 
● Allfusion ERWin: auxilia no projeto de objetos de dados, 
estrutura adequada e elementos-chave para bancos de dados. 
127
● ER/Studio: suporta a modelagem entidade/ relacionamento. 
● Oracle Designer: modela processos de negócio, entidades erelacionamentos de dados que são transformados em projetos 
dos quais aplicações completas e bancos de dados são 
gerados. 
● MetaScope: é uma ferramenta de modelagem de dados de 
baixo custo que suporta a representação gráfica dos dados. 
● ModelSphere: suporta uma variedade de ferramentas de 
modelagem relacional. 
● Visible Analyst: suporta uma variedade de funções de 
modelagem de análise incluindo modelagem de dados. 
 
7.2 Análise estruturada 
As ferramentas de análise estruturada permitem ao engenheiro 
de software criar modelos de dados, modelos de fluxo e modelos 
comportamentais, de modo que favoreça a consistência e a 
verificação de continuidade e facilite a edição e a extensão. Os 
modelos criados com essas ferramentas fornecem ao engenheiro de 
software discernimento da representação de análise e ajuda a 
eliminar erros antes que eles se propaguem no projeto, ou pior, na 
implementação em si. 
As ferramentas dessa categoria usam um “dicionário de dados” 
como banco de dados central para a descrição de todos os objetos 
de dados. Uma vez definidas as entradas no dicionário, diagramas 
entidade/ relacionamento podem ser criados e hierarquias de 
objetos podem ser desenvolvidas. Características de diagramação 
de fluxo de dados permitem a fácil criação desse modelo gráfico e 
habilitam o engenheiro de software a criar modelos 
comportamentais usando diagramas de estado como a notação 
operativa. 
128
As ferramentas listadas abaixo não representam uma 
recomendação e sim uma exemplificação de ferramentas dessa 
categoria de modelagem: 
● AxiomSys: fornece um conjunto completo de ferramentas para 
análise estruturada incluindo extensões para modelagem de 
sistemas de tempo real. 
● MacA&D, WinA&D: fornece um conjunto de ferramentas 
simples e baratas para análise e projeto para máquinas Mac e 
Windows 
● MetaCASE: é uma metaferramenta usada para definir 
métodos de análise e projeto (incluindo análise estruturada): 
seus conceitos, regras, notações e geradores. 
● System Architect: fornece ferramentas na ampla faixa de 
análise e projeto, incluindo ferramentas para modelagem de 
dados e análise estruturada. 
 
7.3 Modelagem de análise em UML 
As ferramentas de modelagem de análise fornecem a 
capacidade de desenvolver modelos baseados em cenário, classe e 
comportamento usando a notação UML. 
As ferramentas dessa categoria suportam todo o conjunto de 
diagramas UML necessário para construir um modelo de análise 
(essas ferramentas também suportam a modelagem de projeto). 
Além disso, para diagramação, ferramentas dessa categoria: a) 
executam verificação de consistência e de correção para todos os 
diagramas UML; b) fornecem ligações para projeto e geração de 
código; c) constroem um banco de dados que permite o 
gerenciamento e a avaliação de grandes modelos UML, necessários 
para sistemas complexos. 
As seguintes ferramentas suportam todo o conjunto de 
129
diagramas UML necessário para modelagem de análise: 
● ArgoUML: é uma ferramenta de código aberto 
● Control Center 
● Enterprise Architect 
● Object Technology Workbench (OTW) 
● Power Designer 
● Rational rose 
● System Architecht 
● UML Studio 
● Visio 
● Visual UML 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
130
 
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 
 
 
 
131
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