Você está na página 1de 230

ANÁLISE E PROJETO DE SISTEMAS

CURSOS DE GRADUAÇÃO – EAD


Análise e Projeto de Sistemas — Prof.ª Claudia Vicci Amadeu, Prof. Ms. Pablo Rodrigo Gonçalves e Prof. Ms. Waine Teixeira Júnior

Meu nome é Claudia Vicci Amadeu. Sou especialista em Análise de Sistemas com ênfase em Arquitetura
Cliente-Servidor pela Pontifícia Universidade Católica de Campinas (PUC-Campinas) e graduada em
Análise de Sistemas. Atuo como docente no curso de Ciência da Computação da Universidade de
Franca (Unifran), trabalhando com as disciplinas de Modelagem de Sistemas, Banco de Dados e
Engenharia de Software.
e-mail: claudia_vicci@yahoo.com.br.

Meu nome é Pablo Rodrigo Gonçalves. Sou Mestre em Engenharia de Produção pela Universidade de
São Paulo − Campus de São Carlos (USP São Carlos). Especialista em Análise de Sistemas pela
Universidade Metodista de Piracicaba (Unimep). Atuo como tecnólogo em Planejamento Administrativo
e Programação Econômica pelas Faculdades Integradas Claretianas de Rio Claro e, também, técnico em
Processamento de Dados. Atualmente leciono no curso de Sistemas de Informação das Faculdades
Integradas Claretianas de Rio Claro.
e-mail: pablorodrigo@uol.com.br

Meu nome é Waine Teixeira Júnior. Sou mestre em Engenharia de Software pelo Instituto de Ciências
Matemáticas e de Computação de São Carlos/SP (ICMC-USP) e bacharel em Ciência da Computação.
Atualmente sou doutorando em Educação pela Universidade Federal de São Carlos (UFSCar). Atuo,
também, como Designer Instrucional na UAB UFSCar.
e-mail: waine.jr@gmail.com

Fazemos parte do Claretiano - Rede de Educação


Claudia Vicci Amadeu
Pablo Rodrigo Gonçalves
Waine Teixeira Júnior

ANÁLISE E PROJETO DE SISTEMAS

Batatais

Claretiano

2013
© Ação Educacional Claretiana, 2010 – Batatais (SP)
Versão: dez./2013

004.21 A492a

Amadeu, Claudia Vicci


Análise e projeto de sistemas / Claudia Vicci Amadeu, Pablo Rodrigo
Gonçalves, Waine Teixeira Júnior – Batatais, SP : Claretiano, 2013.
230 p.

ISBN: 978-85-8377-121-0

1. Modelo Essencial. 2. Processo de desenvolvimento de software. 3. Modelagem


de caso de uso. 3. Modelagem de classes. 4. Modelagem de interações. 5.
Modelagem de Estados. I. Gonçalves, Pablo Rodrigo. II. Teixeira Júnior, Waine.
III. Análise e projeto de sistemas.

CDD 004.21

Corpo Técnico Editorial do Material Didático Mediacional


Coordenador de Material Didático Mediacional: J. Alves
Preparação Revisão
Aline de Fátima Guedes Cecília Beatriz Alves Teixeira
Eduardo Henrique Marinheiro
Camila Maria Nardi Matos
Felipe Aleixo
Carolina de Andrade Baviera Filipi Andrade de Deus Silveira
Cátia Aparecida Ribeiro Juliana Biggi
Dandara Louise Vieira Matavelli Paulo Roberto F. M. Sposati Ortiz
Rafael Antonio Morotti
Elaine Aparecida de Lima Moraes Rodrigo Ferreira Daverni
Josiane Marchiori Martins Sônia Galindo Melo
Lidiane Maria Magalini Talita Cristina Bartolomeu
Luciana A. Mani Adami Vanessa Vergani Machado
Luciana dos Santos Sançana de Melo Projeto gráfico, diagramação e
Patrícia Alves Veronez Montera capa
Raquel Baptista Meneses Frata Eduardo de Oliveira Azevedo
Rosemeire Cristina Astolphi Buzzelli Joice Cristina Micai
Lúcia Maria de Sousa Ferrão
Simone Rodrigues de Oliveira Luis Antônio Guimarães Toloi
Raphael Fantacini de Oliveira
Bibliotecária
Tamires Botta Murakami de Souza
Ana Carolina Guimarães – CRB7: 64/11 Wagner Segato dos Santos

Todos os direitos reservados. É proibida a reprodução, a transmissão total ou parcial por qualquer forma
e/ou qualquer meio (eletrônico ou mecânico, incluindo fotocópia, gravação e distribuição na web), ou o
arquivamento em qualquer sistema de banco de dados sem a permissão por escrito do autor e da Ação
Educacional Claretiana.

Centro Universitário Claretiano


Rua Dom Bosco, 466 - Bairro: Castelo – Batatais SP – CEP 14.300-000
cead@claretiano.edu.br
Fone: (16) 3660-1777 – Fax: (16) 3660-1780 – 0800 941 0006
www.claretiano.edu.br

Fazemos parte do Claretiano - Rede de Educação


SUMÁRIO

CADERNO DE REFERÊNCIA DE CONTEÚDO


1 INTRODUÇÃO ............................................................................................................................................... 9
2 ORIENTAÇÕES PARA ESTUDO......................................................................................................................10
3 REFERÊNCIA BIBLIOGRÁFICA......................................................................................................................23

Unidade 1 – VISÃO GERAL DA ANÁLISE


E PROJETO DE SISTEMAS
1 OBJETIVOS.................................................................................................................................................... 25
2 CONTEÚDOS................................................................................................................................................. 25
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE...........................................................................................26
4 INTRODUÇÃO À UNIDADE...........................................................................................................................27
5 INTRODUÇÃO AO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE...................................................28
6 CONCEITOS FUNDAMENTAIS DE ANÁLISE E PROJETO DE SISTEMAS:
ABSTRAÇÃO, REFINAMENTO E MODULARIDADE......................................................................................36
7 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS........................................................................................38
8 O PERFIL DO PROFISSIONAL QUE REALIZA ANÁLISE E PROJETO DO SOFTWARE...................................44
9 QUESTÕES AUTOAVALIATIVAS....................................................................................................................46
10 C ONSIDERAÇÕES.......................................................................................................................................... 47
11 E-REFERÊNCIAS............................................................................................................................................ 47
12 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................48

Unidade 2 – O MODELO ESSENCIAL


1 OBJETIVO...................................................................................................................................................... 49
2 CONTEÚDOS................................................................................................................................................. 49
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE...........................................................................................49
4 INTRODUÇÃO À UNIDADE...........................................................................................................................51
5 ENFOQUES DA ANÁLISE ESSENCIAL DE SISTEMAS....................................................................................51
6 MODELAGEM AMBIENTAL..........................................................................................................................52
7 MODELAGEM COMPORTAMENTAL............................................................................................................57
8 FERRAMENTAS AUTOMATIZADAS DE APOIO À ANÁLISE ESTRUTURADA...............................................76
9 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................77
10 C ONSIDERAÇÕES.......................................................................................................................................... 78
11 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................79

Unidade 3 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – MODELAGEM


DE CASOS DE USO
1 OBJETIVOS.................................................................................................................................................... 81
2 CONTEÚDOS................................................................................................................................................. 81
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE...........................................................................................82
4 INTRODUÇÃO À UNIDADE...........................................................................................................................82
5 UNIFIED MODELING LANGUAGE – UML....................................................................................................83
6 CONCEPÇÃO DO SISTEMA...........................................................................................................................87
7 CASOS DE USO.............................................................................................................................................. 89
8 APROFUNDANDO CASOS DE USO: INCLUSÃO, EXTENSÃO E GENERALIZAÇÃO......................................100
9 DIAGRAMA DE CASOS DE USO....................................................................................................................104
10 E XEMPLO: SISTEMA LIVRARIA....................................................................................................................104
11 S UGESTÕES RELEVANTES NA ELABORAÇÃO DE MODELAGEM DE CASOS DE USO ...............................111
12 Q UESTÕES AUTOAVALIATIVAS....................................................................................................................111
13 C ONSIDERAÇÕES.......................................................................................................................................... 113
14 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................113
Unidade 4 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – MODELAGEM DE CLASSES
1 OBJETIVOS.................................................................................................................................................... 115
2 CONTEÚDOS................................................................................................................................................. 115
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE...........................................................................................115
4 INTRODUÇÃO À UNIDADE...........................................................................................................................116
5 VISÃO GERAL DA FASE DE ANÁLISE............................................................................................................117
6 INTRODUZINDO OS CONCEITOS DE CLASSE, OBJETO, ATRIBUTOS E MÉTODOS....................................117
7 CONCEITOS FUNDAMENTAIS NO PARADIGMA DA ORIENTAÇÃO A OBJETOS........................................119
8 CLASSES......................................................................................................................................................... 120
9 OBJETOS........................................................................................................................................................ 129
10 O S ESTÁGIOS DO MODELO DE CLASSES.....................................................................................................130
11 D ESCOBRIR AS CLASSES............................................................................................................................... 132
12 MODELO DE CLASSES.................................................................................................................................. 133
13 E XEMPLO: SISTEMA LIVRARIA....................................................................................................................134
14 Q UESTÕES AUTOAVALIATIVAS....................................................................................................................136
15 C ONSIDERAÇÕES.......................................................................................................................................... 138
16 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................138

Unidade 5 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – MODELAGEM DE INTERAÇÕES


1 OBJETIVOS.................................................................................................................................................... 139
2 CONTEÚDOS................................................................................................................................................. 139
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE ..........................................................................................139
4 INTRODUÇÃO À UNIDADE...........................................................................................................................140
5 DA ANÁLISE AO PROJETO............................................................................................................................140
6 ATIVIDADES REALIZADAS NA FASE DE PROJETO.......................................................................................141
7 O QUE FOI PRODUZIDO ATÉ O MOMENTO................................................................................................142
8 OS MODELOS QUE COMPÕEM A MODELAGEM DE INTERAÇÕES...........................................................143
9 OS ELEMENTOS QUE COMPÕEM A MODELAGEM DE INTERAÇÕES........................................................144
10 D IAGRAMA DE SEQUÊNCIA.........................................................................................................................145
11 D IAGRAMA DE COMUNICAÇÃO..................................................................................................................150
12 C ONSTRUÇÃO MODULAR DE DIAGRAMAS DE INTERAÇÃO.....................................................................153
13 C ONSIDERAÇÕES PARA A CONSTRUÇÃO DO MODELO DE INTERAÇÕES................................................154
14 E XEMPLO: SISTEMA LIVRARIA....................................................................................................................155
15 Q UESTÕES AUTOAVALIATIVAS....................................................................................................................156
16 C ONSIDERAÇÕES.......................................................................................................................................... 157
17 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................157

Unidade 6 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – MODELAGEM DE ESTADOS


1 OBJETIVOS.................................................................................................................................................... 159
2 CONTEÚDOS................................................................................................................................................. 159
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE...........................................................................................159
4 INTRODUÇÃO À UNIDADE...........................................................................................................................160
5 MODELO DE ESTADOS.................................................................................................................................. 160
6 CONSTRUÇÃO DO DIAGRAMA DE ESTADOS..............................................................................................167
7 DIAGRAMA DE ATIVIDADES.........................................................................................................................167
8 QUESTÕES AUTOAVALIATIVAS....................................................................................................................173
9 CONSIDERAÇÕES ......................................................................................................................................... 174
10 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................174

Unidade 7 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – ARQUITETURA DO SISTEMA


1 OBJETIVOS.................................................................................................................................................... 175
2 CONTEÚDOS................................................................................................................................................. 175
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE...........................................................................................175
4 INTRODUÇÃO À UNIDADE...........................................................................................................................176
5 ASPECTOS DA ARQUITETURA DO SISTEMA...............................................................................................177
6 DIAGRAMA DE COMPONENTES..................................................................................................................180
7 CONSTRUÇÃO DO DIAGRAMA DE COMPONENTES...................................................................................184
8 DIAGRAMA DE IMPLANTAÇÃO....................................................................................................................184
9 CONSTRUÇÃO DO DIAGRAMA DE IMPLANTAÇÃO....................................................................................185
10 D IAGRAMA DE INTERAÇÃO GERAL.............................................................................................................186
11 C ONSIDERAÇÕES IMPORTANTES SOBRE AS CAMADAS DE INTERFACE E DE PERSISTÊNCIA.................186
12 Q UESTÕES AUTOAVALIATIVAS....................................................................................................................192
13 C ONSIDERAÇÕES ......................................................................................................................................... 193
14 R EFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................194

Unidade 8 – ESTUDO DE CASO: SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE


1 OBJETIVOS.................................................................................................................................................... 195
2 CONTEÚDOS................................................................................................................................................. 195
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE...........................................................................................196
4 INTRODUÇÃO À UNIDADE...........................................................................................................................196
5 DESCRIÇÃO DO SISTEMA............................................................................................................................. 197
6 REQUISITOS DO SISTEMA............................................................................................................................197
7 DOCUMENTAÇÃO DAS REGRAS DE NEGÓCIO...........................................................................................200
8 DOCUMENTAÇÃO DO MODELO DE CASOS DE USO..................................................................................202
9 DOCUMENTAÇÃO DO MODELO DE CLASSES.............................................................................................208
10 G LOSSÁRIO................................................................................................................................................... 210
11 D OCUMENTAÇÃO DO MODELO DE INTERAÇÕES......................................................................................211
12 D OCUMENTAÇÃO DO MODELO DE CLASSES DE PROJETO.......................................................................214
13 D OCUMENTAÇÃO DO MODELO DE ATIVIDADES.......................................................................................215
14 T UTORIAL – ASTAH COMMUNITY...............................................................................................................216
15 Q UESTÃO AUTOAVALIATIVA........................................................................................................................229
16 C ONSIDERAÇÕES.......................................................................................................................................... 229
17 REFERÊNCIAS BIBLIOGRÁFICAS.................................................................................................................230
Caderno de
Referência de
Conteúdo
CRC

Conteúdo–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Conceitos e princípios de Análise de Sistemas. O processo de desenvolvimento do software segundo a Norma NBR
ISO/IEC 12207. Ciclo de vida Clássico. O perfil do profissional que realiza análise e projeto do software. Análise Essen-
cial de sistemas e suas abordagens e ferramentas de modelagem. O paradigma da tecnologia da orientação a objetos
– Modelagem de classes. Modelagem UML (Unified Modeling Language). Modelagem de interações. Modelagem de
Estados. Arquitetura do Sistema.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

1. INTRODUÇÃO
O Caderno de Referência de Conteúdo de Análise e Projeto de Sistemas tem o objetivo de
apresentar a você os conceitos e técnicas que envolvem todo o processo de desenvolvimento
de software.
Considerado como um grande desafio, o desenvolvimento de software exige grande esfor-
ço por parte do desenvolvedor. Este profissional precisa ter uma formação sólida sob diversos
aspectos que vão desde o conhecimento técnico (conhecimento sobre as diversas técnicas e
tecnologias relacionadas à área) até a forma como trabalhar com pessoas, quer sejam elas com
conhecimentos técnicos da área (como aquelas que compõem sua equipe) ou, também, aquelas
que não possuem conhecimentos técnicos, mas que serão usuárias dos sistemas de software
que serão desenvolvidos.
Todo sistema de software, ao ser desenvolvido, passa por algumas etapas específicas. Ao
conjunto dessas etapas, denominamos "ciclo de vida" de um software. Logo mais, você estu-
dará cada uma delas. Entretanto, duas dessas fases são de nosso interesse e objetos de nosso
estudo: a análise e o projeto de software. Você conhecerá o que acontece em cada uma, quais
documentos devem ser produzidos e quais são as pessoas relacionadas ao sistema, que estarão
envolvidas.
10 © Análise e Projeto de Sistemas

A etapa de análise envolve o trabalho de um profissional da área (por exemplo, um analis-


ta de sistemas) juntamente com pessoas que farão uso do sistema, e que tenham conhecimento
do domínio do problema para que o analista conheça as necessidades dos usuários do sistema
a ser desenvolvido e, assim, especificar uma solução para ele.
Na fase de análise. Portanto, a preocupação está em se descobrir uma solução para o
sistema, ou seja, "o que" o sistema deve fazer. Aqui não existe preocupação com as restrições
tecnológicas, isto é, qualquer tarefa realizada nesta etapa não necessita de uma definição sobre
a linguagem de programação ou banco de dados no qual o sistema será implementado.
A etapa de projeto visa o desenvolvimento de uma estratégia para a execução da solução
encontrada na fase anterior. Aqui são necessárias decisões que envolvem o desempenho e a
otimização do sistema, os recursos (tanto de software quanto de hardware), entre outros.
A tarefa de desenvolvimento de software evoluiu com o passar do tempo e com os avan-
ços tecnológicos, tanto em relação ao hardware quanto ao software. Portanto, as técnicas para
a modelagem e o desenvolvimento de programas também mudaram.
Assim, você conhecerá duas abordagens de extrema importância na história do desenvol-
vimento de software: a análise e o projeto fundamentados em funções (processos), e a análise e
o projeto orientados a objetos. São dois paradigmas diferentes de desenvolvimento de software,
mas de grande importância. Com a evolução tecnológica, atualmente a segunda abordagem é a
mais utilizada e, portanto, ela será objeto de estudo mais aprofundado.
Após essa introdução, apresentaremos, a seguir, no tópico Orientações para estudo, al-
gumas orientações de caráter motivacional, dicas e estratégias de aprendizagem que poderão
facilitar o seu estudo.

2. ORIENTAÇÕES PARA ESTUDO

Abordagem Geral
Neste tópico, apresenta-se uma visão geral do que será estudado neste Caderno de Refe-
rência de Conteúdo. Aqui, você entrará em contato com os assuntos principais deste conteúdo
de forma breve e geral e terá a oportunidade de aprofundar essas questões no estudo de cada
unidade. No entanto, essa Abordagem Geral visa fornecer-lhe o conhecimento básico necessá-
rio a partir do qual você possa construir um referencial teórico com base sólida – científica e cul-
tural – para que, no futuro exercício de sua profissão, você a exerça com competência cognitiva,
ética e responsabilidade social.
Este estudo aborda os aspectos do desenvolvimento da análise e projeto de sistemas de
software. Pensando em todo o ciclo de desenvolvimento de um sistema, você verá desde o
momento da concepção do software (momento em que se percebe a necessidade da criação
de um novo software ou mesmo da reformulação de um já existente) até o momento em que é
planejado.
Além disso, você verá, também, que para desenvolver um sistema de software é necessá-
rio que se adote uma metodologia. A era de desenvolvimento de software passa por duas abor-
dagens muito importantes, que definem de formas diferentes todas as etapas de planejamento
e desenvolvimento: a análise estruturada (também conhecida, em sua evolução, como análise
essencial), e a análise e projeto orientados a objetos.
Iniciaremos nossos estudos visando que você compreenda como podem ser utilizados
os métodos, os procedimentos, as técnicas e as ferramentas na organização das atividades de
© Caderno de Referência de Conteúdo 11

análise e projeto, de forma que o processo de desenvolvimento leve ao desenvolvimento de


software com qualidade.
Você deverá compreender o que é o ciclo de vida do software, e como as atividades e tarefas
que o compreendem estão relacionadas. É importante, ainda, entender que essas atividades e tare-
fas estão, também, integradas com muitas outras, tais como as atividades gerenciais e de apoio.
O Analista de Sistemas é o profissional responsável pelo desenvolvimento dos sistemas de
software. Deve trazer, em sua formação, as habilidades e competências para a execução das ta-
refas de desenvolvimento de software, em especial, aquelas relacionadas com a análise, proje-
to, implementação, teste e implantação. Essas podem ser adquiridas por meio de curso superior
em informática, como o de Análise de Sistemas ou Sistemas de Informação.
O desenvolvimento de tecnologias de hardware já foi um grande desafio nos primórdios
da era computacional. Diversas características inerentes aos computadores eram consideradas
fatores limitadores da expansão da tecnologia, como tamanho, custo e desempenho. Com a
evolução tecnológica, houve uma inversão desse desafio, que passou a ser do software, e não
mais do hardware, cujos componentes tiveram seu tamanho reduzido (miniaturização), favore-
cendo o uso da informática
Atualmente, é preocupação das empresas a redução do custo e o aumento da qualidade,
quando se trata do desenvolvimento de software, o que torna mais desafiador o papel do Ana-
lista de Sistemas.
E, quando se trata dos aspectos da produção de software, temos a Engenharia de Softwa-
re, área responsável pelo desenvolvimento dos métodos, técnicas e ferramentas utilizados na
produção de software.
Assim, se ele é obtido por meio de um processo produtivo, então é considerado como uma
categoria de produto e, como tal, deve receber cuidados no processo de produção, de forma
que garanta sua qualidade durante o processo de desenvolvimento.
Nesse sentido, muitos esforços são empregados para melhorar os produtos e serviços, o
que levou à definição de várias normas e padrões, como a norma NBR ISO/IEC.
No entanto, como o software é "pensado" para ser produzido? Podemos dizer que todo o
processo que abrange desde a ideia de se construir um software até o momento em que ele é
produzido, é conhecido como ciclo de vida do software.
Vimos, na Introdução, que a análise e o projeto de um sistema são duas etapas do ciclo de
vida dele. Por ciclo de vida de um sistema, entende-se todas as etapas que compõem o processo
de desenvolvimento de um software.
Esse ciclo tem início na fase de entendimento daquilo que se espera desenvolver; segue
pela fase de construção em que são definidas as especificações técnicas sobre a solução encon-
trada para o desenvolvimento do sistema, que venham a atender às necessidades dos usuários,
além da própria produção do software; a fase de implantação, na qual o software é preparado
para ser instalado no ambiente do cliente; e, finalizando, a fase de manutenção criada para per-
mitir a evolução do software e/ou para correção de eventuais problemas que possam não ter
sido notados pela fase de testes.
É importante ressaltar que essas fases podem estar divididas e nomeadas de forma um
pouco diferente, apenas englobando mais detalhes. Entretanto, de uma forma geral, o ciclo de
vida de qualquer sistema deve passar pelas etapas de: concepção, análise, projeto, implementa-
ção, teste, implantação e manutenção.

Claretiano - Centro Universitário


12 © Análise e Projeto de Sistemas

Essas etapas estão totalmente interligadas, uma vez que cada uma é, praticamente, continu-
ação daquela que a antecede. Você será apresentado a cada uma dessas etapas, e poderá obser-
var o que ocorre nelas, bem como os artefatos (documentos) que são produzidos em cada uma.
O desenvolvimento de um software pode ser resumido em algumas atividades.
A primeira atividade é a implementação do processo. As tarefas desta atividade são, nor-
malmente, de competência de um gerente de projetos e resumem-se em definir uma metodo-
logia de desenvolvimento, escolha de ferramentas e planejamento e documentação do que se
deseja do produto a ser desenvolvido.
A segunda atividade é a análise dos requisitos do sistema. Nela, procura-se entender o
problema (domínio do sistema), de forma mais ampla e, não necessariamente, de maneira pro-
funda. Como resultado é gerada uma proposta de solução geral, na qual são discutidas questões
relacionadas ao próprio sistema, além daquelas relacionadas com a tecnologia e os recursos
humanos.
O desenho da arquitetura do sistema corresponde à terceira atividade no processo de
desenvolvimento do software. Nela são levantados os requisitos do sistema.
Na quarta atividade, ocorre a análise dos requisitos do software, de responsabilidade do
analista de sistemas. Englobam as tarefas de levantamento dos requisitos com os usuários do
sistema, sua especificação e modelagem.
A quinta atividade trata do desenho da arquitetura do software. Ela permite a compre-
ensão do conceito de arquitetura incluindo a organização global e hierárquica dos módulos que
irão compor o software.
Na sexta atividade é feito o desenho detalhado do software, com a especificação deta-
lhada de todos os componentes para o software, além das estruturas de dados necessárias.
A sétima atividade refere-se à codificação e ao teste do software. Trata-se da escolha de
uma linguagem computacional, na qual os códigos de programas são escritos. Os testes são rea-
lizados para garantir que o software desenvolvido não contenha erros e atenda às necessidades
dos usuários, conforme especificação realizada na etapa de análise.
E, finalmente, a integração do software é a oitava atividade. Nela, os diferentes módulos
do software desenvolvido são integrados para compor um produto homogêneo quando eles
operarem em conjunto.
Estudaremos, portanto, duas abordagens de desenvolvimento de sistemas: a abordagem
da Análise e Projetos Estruturados (cuja evolução máxima recebe o nome de Análise Essencial),
utilizada para investigar sistemas já desenvolvidos, por exemplo, para documentação – ou redo-
cumentação, caso ela tenha se perdido – de software ou de novos projetos que utilizarão o pa-
radigma da programação estruturada. E, a abordagem da Análise e Projeto Orientados a Objetos
que, atualmente, é a mais utilizada.
Iniciamos, então, com a Análise e Projetos Estruturados. Lembramos que, independen-
temente da abordagem de desenvolvimento adotada, a premissa básica é descrever o sistema
de maneira livre de quaisquer restrições tecnológicas (linguagens de programação, sistemas
operacionais etc.).
Nesta abordagem, o problema em estudo pode ser visto sob dois aspectos: o primeiro se
refere ao ambiente no qual os elementos relacionados ao problema e sua solução se encon-
tram (visão externa); e, o segundo, se refere à forma como acontecem as reações do sistema
como resposta aos estímulos externos sofridos pelo sistema (visão interna). Ao enfoque dado
por essas duas visões dá-se o nome de modelagem ambiental e modelagem comportamental,
respectivamente.
© Caderno de Referência de Conteúdo 13

Podemos resumir as três atividades desenvolvidas no modelo ambiental como:


• Elaboração da declaração dos objetivos do sistema: trata-se da compreensão e defini-
ção dos objetivos do sistema, de forma que seu escopo possa ser delimitado. A partir
da compreensão dos objetivos do sistema, deve ser elaborada uma declaração, espe-
cificando os requisitos que o sistema deve atender, assim como às necessidades dos
usuários. Esta etapa é realizada com os usuários, por meio de entrevistas nas quais eles
manifestam seus interesses e necessidades pelo sistema. Lembramos que a presença
dos usuários nesta fase de levantamento de requisitos é fundamental, uma vez que eles
são os mais interessados no sistema e conhecem todo o processo a ser informatizado.
• Elaboração do diagrama de contexto: neste diagrama o sistema é mostrado como um
único processo. Sua representação é feita por meio de um círculo conectado aos ele-
mentos do ambiente, chamados entidades externas, pelos fluxos de entrada e fluxos
de saída, representados por setas. Esse diagrama mostra o sistema como uma "caixa-
preta", o que significa que nada se conhece sobre como o sistema reage, internamente,
para responder aos estímulos provocados no ambiente.
• Construção da lista de eventos: é formada pelos eventos identificados para o sistema.
Evento é uma atividade essencial, que ocorre em razão de um estímulo externo, so-
frido pelo sistema, ao qual ele responde por meio de uma reação (princípio da ação e
reação). Podemos entender o estímulo como uma mensagem para o sistema.
Os estímulos são os elementos ativadores das funções dos sistemas, e são provocados por
diversos tipos de acontecimentos ou eventos do mundo exterior, que requerem do sistema uma
resposta predeterminada. Ao produzir uma resposta a um dado evento, o sistema retorna ao
estado de inatividade até ser estimulado novamente por outro evento da mesma ou de outra
natureza.
A segunda abordagem a ser estudada refere-se aos sistemas de software orientados a
objetos, ou seja, a abordagem da análise e projeto orientados a objetos. Difere-se da primeira
porque, ao invés de enfatizar as funções ou processos que compõem o sistema, a ênfase está na
descoberta dos objetos que representam o sistema.
Para a representação de seus diagramas, essa abordagem faz uso da UML (Unified Mode-
ling Language), uma linguagem visual, utilizada para modelar os sistemas orientados a objetos.
Com ela você pode modelar, especificar, construir ou documentar seus sistemas. Ela não depen-
de da linguagem de programação utilizada na implementação do sistema, nem do processo de
desenvolvimento do software.
Outra vantagem apresentada pela UML está na existência de mecanismos de extensibi-
lidade e especialização, que permitem a ampliação de conceitos conforme novas necessida-
des surgem. Trata-se de uma linguagem de notação em razão dos diversos elementos gráficos
existentes para a elaboração dos diagramas definidos por ela. Estes, por sua vez, são dotados
de sintaxe, uma vez que cada desenho é, graficamente, representado de uma maneira, e de se-
mântica, porque cada diagrama ou elemento que os formam carregam um significado em si.
Dessa forma, cada diagrama revela aspectos diferentes do sistema, por meio de visões
que eles proporcionam do sistema na representação dos modelos.
Os diagramas gerados pela UML são chamados artefatos. A UML evoluiu desde a época de
seu surgimento e, a partir da versão 2.0 passou a definir treze diagramas. A primeira categoria
refere-se aos diagramas estruturais (ou estáticos), que representam as diferentes estruturas do
sistema, enfatizando sua organização. E, a segunda categoria, que são os diagramas comporta-
mentais (ou dinâmicos), que enfatizam a dinâmica do sistema.
Os diagramas que compõem a UML e suas principais características são:

Claretiano - Centro Universitário


14 © Análise e Projeto de Sistemas

1) Diagrama de Casos de Uso: apresenta a interação dos atores (aqueles que interagem
com o sistema, como, por exemplo, uma pessoa) com os processos que fazem parte
do sistema, apresentados sob a forma de casos de uso. É importante ressaltar que
este diagrama nada revela sobre como cada processo ocorre, mas sua ênfase está na
participação que cada ator tem nos processos.
2) Diagrama de Classes: mostra como as classes estão relacionadas umas com as outras
no sistema. Representa sua estrutura estática. Os relacionamentos entre as classes
podem ocorrer de diferentes formas e, para cada situação a ser representada, existe
um símbolo que o representa. Os relacionamentos podem ser dos seguintes tipos:
dependência, associação (por agregação ou por composição), por generalização (he-
rança) e, ainda, agrupadas em pacotes. Juntamente com os relacionamentos, o dia-
grama de classes revela a estrutura interna das classes, formada por seus atributos e
operações.
3) Diagrama de Objetos: trata-se de uma variação do diagrama de classes, diferindo dele
por mostrar não apenas a classe (como o diagrama de classes faz), mas sim um nú-
mero de instâncias de objetos das classes. A notação de ambos é muito semelhante.
Entretanto, o diagrama de objetos deve ser utilizado quando queremos exemplificar
diagramas de classes mais complexos, uma vez que é possível enxergar neles as ins-
tâncias dos objetos que formam as classes.
4) Máquina de Estados: representa os diferentes estados pelos quais uma classe de um
sistema pode se apresentar em determinado momento. Um diagrama de máquina de
estados representa os estados relativos a uma única classe. Você pode entender que
cada estado representa um comportamento que a classe assume. Havendo mudança
no comportamento, seu estado é alterado. A mudança de um estado para outro rece-
be o nome de transição de estados. O diagrama revela, ainda, os eventos que levam
à transição de estados (normalmente ocasionados pela troca de mensagens entre os
objetos).
5) Diagrama de Atividades: sua finalidade é a de mostrar as ações executadas durante
um processo do sistema, tanto as sequencializadas como as que ocorrem paralela-
mente. Podemos observar nele os fluxos principais, alternativos, de exceção e concor-
rentes que compõem as atividades de um processo.
6) Diagrama de Sequência: é um diagrama que mostra uma colaboração dinâmica entre
objetos, ou seja, ele mostra as mensagens trocadas entre eles, segundo uma ordem
temporal, conforme os eventos ocorrem.
7) Diagrama de Comunicação: este diagrama tem a mesma finalidade do diagrama de
sequência, diferindo deste por mostrar como os objetos se relacionam, porém, inde-
pendentemente do tempo de execução de cada objeto, isto é, ele não representa o
tempo como uma dimensão separada.
8) Diagrama de Componentes: entenda um componente como uma parte física do siste-
ma, tal como um código-fonte, um componente binário ou um componente executá-
vel, e que pode ser substituído, desde que se garanta a integridade da arquitetura do
sistema. Este diagrama mostra como o software está estruturado fisicamente, e suas
dependências em relação aos componentes de código.
9) Diagrama de Implantação: por meio deste diagrama podemos avaliar a dimensão do
software, pois ele revela a forma como o hardware está organizado pelo ambiente do
sistema e sua ligação com os componentes de software.
10) Diagrama de Estrutura Composta: este diagrama é responsável por revelar de que
forma os elementos que compõem o sistema (classes, interfaces e componentes) es-
tão interconectados no momento de funcionamento do sistema.
11) Diagrama de Tempo: este diagrama apresenta os diferentes estados de um objeto du-
rante o tempo de execução, e sua interação com os demais objetos. Passou a compor
o quadro de diagramas da UML a partir da versão 2.0.
© Caderno de Referência de Conteúdo 15

12) Diagrama de Interação Geral: fornece uma visão geral do sistema por mostrar a inte-
ração entre os diagramas de sequência, comunicação e tempo. Também foi incorpo-
rado à UML a partir da versão 2.0.
O desenvolvimento de software está pautado na Engenharia de Software, uma área voltada
ao desenvolvimento de métodos e técnicas que direcionam os desenvolvedores em suas tarefas.
Vários modelos de processos de software já foram propostos. Todavia, independentemen-
te do modelo escolhido para o desenvolvimento, a Engenharia de Software propõe a divisão
do ciclo de vida do software em quatro etapas: especificação do software, desenvolvimento do
software, validação do software e evolução do software. E, a partir dessa grande divisão, outras
mais detalhadas são propostas.
Ressaltamos que cada fase do ciclo de desenvolvimento de um sistema produz alguns ar-
tefatos (documentos do sistema).
Veja as atividades desenvolvidas nas fases de análise e projeto de um sistema.
Especificação do software: esta etapa contempla as primeiras atividades relacionadas ao
desenvolvimento de software. Inicia-se com a concepção do sistema. Ocorre quando surge a
ideia do desenvolvimento de um software, normalmente por parte do cliente. Envolve um con-
tato inicial do desenvolvedor com o cliente na busca de informações sobre suas necessidades
pelo sistema a ser construído. Dessa forma é que o desenvolvedor poderá descobrir o problema
e propor uma solução para ele.
Pode ser subdividida em: levantamento de requisitos, organização dos requisitos e pla-
nejamento do desenvolvimento. Esta tarefa deve ser rápida, porque se trata, inicialmente, de
uma busca superficial, apenas para se ter uma ideia geral sobre o sistema. A partir das informa-
ções coletadas e da análise da dimensão do problema, aliada às necessidades do cliente, é que
o desenvolvedor chega a uma conclusão sobre a viabilidade do desenvolvimento do sistema. A
esta etapa dá-se o nome de estudo da viabilidade do sistema.
Outra atividade relacionada à fase de concepção é a estimativa de custo, que permitirá
a geração de um contrato de desenvolvimento do sistema, que deve incluir, entre outros de-
talhes, o custo do projeto e um cronograma. A estes documentos gerados em cada etapa do
desenvolvimento de software dá-se o nome de artefatos.
Na fase de levantamento de requisitos o desenvolvedor busca todas as informações pos-
síveis sobre aquilo que se espera do sistema. Para isso, ele conta com a colaboração dos usuá-
rios, além da análise de documentos, de outros sistemas, e até mesmo pela observação sobre
a forma como os usuários interagem com o sistema atual. Esta etapa compreende a geração
dos seguintes artefatos: o documento de especificação dos requisitos e o glossário, este é uma
espécie de dicionário utilizado para definir e padronizar os termos técnicos do domínio da apli-
cação.
Nesta fase ocorre, também, a definição dos casos de uso, que representam um conjunto
de ações executadas por um sistema, representadas pelos processos, e o relacionamento dos
atores (ou agentes externos) com esses processos. Pelos casos de uso nada é revelado sobre a
estrutura e o comportamento interno do sistema.
Os relacionamentos entre os atores e os casos de uso podem ser representados por meio
de notação gráfica disponível na UML. Trata-se do diagrama de casos de uso. Ele revela, em alto
nível de abstração, com quais funcionalidades do sistema cada ator interage. O modelo de casos
de uso pode ser visto como uma "caixa-preta", ou seja, não importa como os casos de uso são
implementados, nem como eles trabalham internamente.

Claretiano - Centro Universitário


16 © Análise e Projeto de Sistemas

Outra fase que faz parte da primeira grande fase da Engenharia de Software é a análise.
Nela, o desenvolvedor deve compreender os requisitos do sistema, para descobrir a solução do
problema proposto pelo sistema.
O documento gerado chama-se especificação do sistema, que pode ser escrito em lingua-
gem natural ou em linguagem estruturada. Quando escrito em linguagem natural, apresenta a
descrição do problema sob a forma de texto. Como desvantagem, pode apresentar enunciados
ambíguos, incompletos e inconsistentes. Já, sob a forma de linguagem estruturada, apresenta-
se mais padronizado, pois utiliza formulários (templates) que limitam um pouco a forma de
escrever os requisitos.
Em consequência à compreensão dos requisitos, vem a descoberta dos conceitos, ou objetos,
que farão parte do sistema. Dentro da concepção da orientação a objetos, sabemos que os objetos se
agrupam em classes. Para representar esses conceitos e os relacionamentos entre eles, a UML dispõe
de um conjunto de notações. Trata-se do diagrama de classes considerado um dos mais importantes
no processo de desenvolvimento de software. Descreve o aspecto estático do sistema, mostrando as
classes, seus relacionamentos e as multiplicidades relacionadas a eles.
Assim como um objeto é considerado uma instância de uma classe, o diagrama de objetos é
essencialmente uma instância de um diagrama de classes.
As próximas etapas do desenvolvimento de um software enquadram-se na segunda grande
fase definida pela Engenharia de Software, que trata os aspectos do desenvolvimento do software.
Terminada a fase de análise, inicia-se a fase de projeto, que tem dois estágios: projeto de
sistemas e projeto de classes.
O projeto de sistemas refere-se aos aspectos da arquitetura do software na resolução do
problema da aplicação. O projeto de classes utiliza os modelos gerados na fase de análise, ajustan-
do-os e preparando-os para a implementação.
Nesses dois estágios da fase de projeto são realizadas as seguintes tarefas:
a) Detalhamento dos aspectos dinâmicos: atividades relacionadas com a produção da mo-
delagem dinâmica, como os modelos de interações, estados e atividades.
b) Refinamento dos aspectos estáticos e estruturais: o modelo de classes passa por três
importantes estágios, quais sejam, o modelo de classes de análise (em que ocorre a des-
coberta dos conceitos); o modelo de classes de projeto (relaciona-se com a representa-
ção dos objetos de persistência do sistema); e o modelo de classes de implementação,
que trata da tradução dos modelos para códigos de programas. Esta etapa é responsável
pelo refinamento dos aspectos estático e estrutural das classes de análise para a gera-
ção das classes de projetos, providas de atributos, operações e associações.
c) Projeto de arquitetura: nesta fase é realizada a decomposição do sistema em subsiste-
mas para distribuir os componentes, fisicamente, pelos equipamentos em que serão
executados. Ainda são tomadas medidas em relação à definição das interfaces, reutiliza-
ção de componentes e outras.
d) Persistência de objetos: refere-se ao armazenamento das informações. Portanto, aqui,
as atividades se referem ao controle de transações, mecanismos de armazenamento e
ao mapeamento do modelo de objetos para o relacional.
e) Projeto de interface gráfica com o usuário: refere-se à forma de interação entre usuá-
rio e sistema. Consideram-se os aspectos abordados na Interação Humano-Computador
(IHC), dentre eles o de usabilidade.
f) Projeto de algoritmos: nesta fase são elaborados os diagramas de atividades, pois eles
permitem, com mais facilidade, a compreensão do problema. Outra atividade desta fase
refere-se à escolha dos algoritmos que serão usados na implementação.
© Caderno de Referência de Conteúdo 17

A criação da modelagem de interações também faz parte da fase de projeto. Por meio dela
são descritas as sequências das mensagens trocadas entre os objetos que participam de um caso
de uso.
O modelo de interações representa as mensagens que os objetos trocam entre si, para a
execução de cenários dos casos de uso do sistema. Ajuda no refinamento do modelo de classes,
identificando as operações e atributos das classes que compõem o modelo de classes. Permite,
também, a compreensão dos aspectos dinâmicos do sistema de software e auxilia na documenta-
ção desses aspectos.
Os diagramas responsáveis pela modelagem de interações são chamados diagramas de in-
teração. São eles: diagrama de sequência e diagrama de comunicação. Ambos representam as
mensagens trocadas entre os objetos, com a diferença que os diagramas de sequência enfatizam
a forma como as mensagens são trocadas no decorrer do tempo, enquanto nos diagramas de co-
municação a ênfase está nos relacionamentos entre os objetos.
Os modelos de estados e de atividades também fazem parte da fase de projeto. O diagrama
de estados representa os diferentes estados em que uma classe pode se encontrar em determina-
do instante no tempo, ou seja, ele revela os comportamentos assumidos pela classe em razão da
ocorrência de estímulos externos. Revela as mudanças que ocorrem nos objetos, provocadas por
estímulos externos (eventos).
O diagrama de atividades revela os estados de uma atividade e, por isso, é considerado um
tipo especial de diagrama de estados. Assim como o modelo de interações, o modelo de estados é
classificado como modelagem dinâmica, isto é, descreve o comportamento dos objetos.
A etapa de implementação é a última da fase de desenvolvimento do software. Aqui, o
problema proposto foi compreendido, e a solução para ele se encontra nos diferentes diagramas
construídos. Assim, encerram-se as fases de análise e projeto, para dar início à geração do código
do sistema.
O projeto de arquitetura é a fase em que ocorre a divisão do sistema de software orientado a
objetos (SSOO) em subsistemas. Estes compõem o software e interagem entre si, em colaboração,
para a realização das tarefas de responsabilidade do sistema. Pode ser visto sob dois aspectos: o
da arquitetura lógica, e o da arquitetura física.
O primeiro está focado nos objetos e seus relacionamentos, o que ressalta a importância
da definição das classes e sua distribuição entre os subsistemas. Graficamente, sua representação
ocorre por meio do diagrama de subsistemas, disponível na UML para essa finalidade.
O segundo aspecto refere-se à estrutura física, ou seja, define como os subsistemas serão dis-
tribuídos pelos nós de processamento, suas interdependências e distribuição pelas camadas lógicas
do sistema. A UML tem duas categorias de diagramas, chamadas diagramas estruturais, para repre-
sentar essa distribuição. São eles: o diagrama de componentes e o diagrama de implantação.
Chegamos, assim, ao final do nosso estudo. Você teve a oportunidade de compreender que
o desenvolvimento de projetos de sistemas de software não é uma tarefa simples e, dessa forma,
você pôde perceber que analisar e projetar sistemas requer muito conhecimento, bom senso,
criatividade, organização e muita prática.

Glossário de Conceitos
O Glossário de Conceitos permite a você uma consulta rápida e precisa das definições con-
ceituais, possibilitando-lhe um bom domínio dos termos técnico-científicos utilizados na área de
conhecimento dos temas tratados em Análise e Projeto de Sistemas. Veja, a seguir, a definição
dos principais conceitos:

Claretiano - Centro Universitário


18 © Análise e Projeto de Sistemas

1) ABNT: Associação Brasileira de Normas Técnicas: é uma organização responsável no


Brasil pelo estabelecimento de normas técnicas de qualidade.
2) Abstração: um dos princípios básicos da orientação a objetos, que consiste em realçar
apenas os aspectos essenciais de uma entidade. Considerando-se os objetos como o
artefato mais importante do sistema, abstrair significa compreender o significado do
objeto e o seu papel no sistema.
3) Análise: fase do desenvolvimento do software que enfatiza a investigação do proble-
ma. Nesta fase descobre-se "o que" o sistema deve fazer, ou seja, busca-se solução
para o problema e, depois, descreve-se o problema e seus requisitos.
4) Análise e projeto estruturados: a decomposição de um problema é feita por meio de
funções e processos, sendo por isso também conhecidos como análise e projeto orien-
tados à função, o que resulta em processos compostos por subprocessos.
5) Análise e projeto orientados a objetos: a decomposição de um problema é feita por
meio de objetos.
6) Analista de Negócios: é um profissional que, geralmente, tem uma informação em
tecnologia e muita vivência ou experiência em negócios.
7) CASE: uma ferramenta CASE (do inglês Computer-Aided Software Engineering) é uma
classificação que abrange toda ferramenta baseada em computadores que auxiliam
atividades de Engenharia de Software, desde análise de requisitos e modelagem até
programação e testes. (Disponível em: <http://pt.wikipedia.org/wiki/Ferramenta_
CASE>. Acesso em: 10 jan. 2011).
8) Classe: descreve um grupo de objetos com características semelhantes, ou seja, com
as mesmas propriedades (atributos), comportamento (operações), relacionamentos e
significado (semântica).
9) Cenário: refere-se a uma determinada sequência de ações que ocorrem em um sis-
tema, ilustrando o seu comportamento. Em se tratando de casos de uso, um cenário
pode ser visto como uma instância de um caso de uso.
10) Diagrama: conjunto de elementos básicos e suas relações, com o objetivo de ilustrar
um modelo.
11) Engenharia de requisitos: área responsável pelo levantamento dos requisitos de um
sistema de software, identificação e gerenciamento dos mesmos no sistema.
12) Fases típicas de um processo de desenvolvimento de software: concepção, análise,
projeto, implementação, testes, implantação, manutenção e evolução.
13) Modelagem arquitetural: em sistemas de software orientados a objetos, a modela-
gem arquitetural refere-se à criação de modelos que descrevem a fase de implemen-
tação e instalação do sistema de software. Os modelos refletem como os componen-
tes do sistema (programas, dados, documentação, computadores, impressoras, entre
outros) ficarão distribuídos pelos nós e, também, pelas diferentes plataformas. Repre-
sentada pelos diagramas de componentes e de implantação.
14) Modelagem comportamental: em sistemas de software orientado a objetos, a mo-
delagem comportamental se refere à interação que ocorre entre os objetos, por meio
de trocas de mensagens. Por meio dos diagramas é possível representar os estados
de um objeto e seu comportamento. É a modelagem dinâmica. Representada pelos
diagramas de interação, diagramas de estados e diagramas de atividades.
15) Modelagem estruturada: em sistemas de software orientados a objetos, a modela-
gem estruturada se refere à identificação das classes, dos objetos e dos relacionamen-
tos entre as classes. Representada mais especificamente pelos diagramas de classes e
diagramas de objetos. É a modelagem estática.
16) Modelagem de sistema de software: refere-se à criação de modelos, por meio de
notações gráficas e textuais, que representem as partes essenciais de um sistema de
software.
© Caderno de Referência de Conteúdo 19

17) Modelo: é a abstração de algo, com o objetivo de se compreender este algo antes de
sua construção.
18) Objeto: também conhecido como instância de uma classe. Pode ser descrito como
um conceito, um elemento do mundo real ou uma abstração, que possui identidade e
significado para uma aplicação.
19) Paradigma da orientação a objetos: uma nova maneira de pensar nos sistemas, ou seja,
utilização de modelos que são organizados a partir de conceitos do mundo real. Na dé-
cada de 1990 surgem métodos e notações para modelagem para esse paradigma. Tam-
bém considerada uma metodologia de programação em que o objeto é o componente
mais importante.
20) Processo de desenvolvimento de software: método utilizado para organizar todas as
atividades relacionadas com a produção de software, como planejamento, criação, tes-
tes, entrega e manutenção.
21) Projeto: fase do desenvolvimento do software que enfatiza uma solução lógica. Nesta
fase busca-se descobrir "como" o sistema atende os requisitos e as restrições.
22) Qualidade: o conceito de qualidade está no equilíbrio entre os seguintes fatores: quali-
dade do produto ou serviço, custo e atendimento (WEBER, 1997).
23) Sistema: de acordo com Stair (1998), um sistema é um conjunto de elementos ou com-
ponentes que interagem para que os objetivos sejam atingidos. Os sistemas têm entra-
das, mecanismos de processamento, saídas e feedback. Vários tipos de sistemas podem
ser implementados em um software. Daí o trabalho de análise de sistemas.
24) Sistema de Software: conjunto de programas de computador, com finalidades específi-
cas, que interagem entre si com o objetivo de fornecer funcionalidades para a solução
de determinados problemas. O desenvolvimento desse tipo de sistema envolve o uso
de tecnologias, tais como linguagens de programação, sistemas gerenciadores de banco
de dados, sistemas operacionais (diferentes plataformas), padrões de projetos, redes de
computadores, entre outras.
25) Software: Programas de computador e documentação associada. Os produtos de sof-
tware podem ser desenvolvidos para um cliente específico ou para um mercado geral
(SOMMERVILLE, 2007).
26) Stakeholder: em se tratando de desenvolvimento de software, o termo se refere às pes-
soas envolvidas na produção do sistema, como engenheiro de software, gerente de pro-
jeto, analista, projetista, programador, cliente, usuário, entre outros.
27) Unified Modeling Language: ou UML – (Linguagem de Modelagem Unificada). É uma
linguagem de notação, independente de linguagens de programação e de processos de
desenvolvimento, utilizada para especificar, construir, visualizar e documentar os arte-
fatos de um sistema de software orientado a objetos. Surgiu na década de 1990, de um
esforço em se padronizar a forma de modelar software orientado a objetos.
28) Verificação e validação de software: é um conjunto de processos que buscam levantar
defeitos ao longo do desenvolvimento de um projeto de software, com o intuito de ten-
tar descobrir, o mais cedo possível, problemas no projeto. Para isso, utilizamos revisões
e testes bem planejados e conduzidos e, ao final, realizamos a validação pelos futuros
usuários, antes de ser entregue.

Esquema dos Conceitos-chave


Para que você tenha uma visão geral dos conceitos mais importantes deste estudo, apre-
sentamos, a seguir (Figura 1), um Esquema dos Conceitos-chave. O mais aconselhável é que você
mesmo faça o seu esquema de conceitos-chave ou até mesmo o seu mapa mental. Esse exercício é
uma forma de você construir o seu conhecimento, ressignificando as informações a partir de suas
próprias percepções.
É importante ressaltar que o propósito desse Esquema dos Conceitos-chave é representar,
de maneira gráfica, as relações entre os conceitos por meio de palavras-chave, partindo dos mais
complexos para os mais simples. Esse recurso pode auxiliar você na ordenação e na sequenciação
hierarquizada dos conteúdos de ensino.
Claretiano - Centro Universitário
20 © Análise e Projeto de Sistemas

Com base na teoria de aprendizagem significativa, entende-se que, por meio da organiza-
ção das ideias e dos princípios em esquemas e mapas mentais, o indivíduo pode construir o seu
conhecimento de maneira mais produtiva e obter, assim, ganhos pedagógicos significativos no seu
processo de ensino e aprendizagem.
Aplicado a diversas áreas do ensino e da aprendizagem escolar (tais como planejamentos de
currículo, sistemas e pesquisas em Educação), o Esquema dos Conceitos-chave baseia-se, ainda,
na ideia fundamental da Psicologia Cognitiva de Ausubel, que estabelece que a aprendizagem
ocorre pela assimilação de novos conceitos e de proposições na estrutura cognitiva do aluno. As-
sim, novas ideias e informações são aprendidas, uma vez que existem pontos de ancoragem.
Tem-se de destacar que "aprendizagem" não significa, apenas, realizar acréscimos na es-
trutura cognitiva do aluno; é preciso, sobretudo, estabelecer modificações para que ela se con-
figure como uma aprendizagem significativa. Para isso, é importante considerar as entradas de
conhecimento e organizar bem os materiais de aprendizagem. Além disso, as novas ideias e os
novos conceitos devem ser potencialmente significativos para o aluno, uma vez que, ao fixar es-
ses conceitos nas suas já existentes estruturas cognitivas, outros serão também relembrados.
Nessa perspectiva, partindo-se do pressuposto de que é você o principal agente da cons-
trução do próprio conhecimento, por meio de sua predisposição afetiva e de suas motivações
internas e externas, o Esquema dos Conceitos-chave tem por objetivo tornar significativa a sua
aprendizagem, transformando o seu conhecimento sistematizado em conteúdo curricular, ou
seja, estabelecendo uma relação entre aquilo que você acabou de conhecer com o que já fazia
parte do seu conhecimento de mundo (adaptado do site disponível em: <http://penta2.ufrgs.
br/edutools/mapasconceituais/utilizamapasconceituais.html>. Acesso em: 11 mar. 2010).
© Caderno de Referência de Conteúdo 21

Paradigmas de
Desenvolvimento
Análise de Software
Software Análise e Projeto
 Orientados a
Essencial
 Objetos

Decomposição por
funções ou processos Fases do Processo Decomposição por
objetos ou conceitos
de
Desenvolvimento
Funções/Processos de Software
Software
Objetos

Ciclo
Concepção Iterativo/Incremental

Análise

Projeto

Implementação Solução Lógica


Investigação do
Problema
Testes

Domínio da
Solução
Domínio do Implantação
Problema

Operação

Domínio da
Manutenção Realização
Evolução

Modelo Modelo Modelo de Modelo de Modelo de


Ambiental Comportamental Classes Estados Interações

Análise Essencial UML

Figura 1 Esquema dos Conceitos-chave do Caderno de Referência de Conteúdo de Análise e Projeto de Sistemas.
Como você pode observar, esse Esquema dá a você, como dissemos anteriormente, uma
visão geral dos conceitos mais importantes deste estudo. Ao segui-lo, você poderá transitar en-
tre um e outro conceito e descobrir o caminho para construir o seu processo de ensino-apren-
dizagem. O esquema apresenta os dois paradigmas bastante utilizados no desenvolvimento de
software, que são a Análise Essencial (ou Análise e Projeto Estruturados), que decompõe o
problema por funções ou processos, e a Análise e Projeto Orientados a Objetos, que decompõe
o problema por objetos ou conceitos. Independentemente do paradigma de desenvolvimento,
as fases de desenvolvimento de um sistema de software são praticamente as mesmas (concep-
ção, análise, projeto, implementação, testes, implantação, operação, manutenção e evolução).
O que muda é a forma de desenvolvimento.

Claretiano - Centro Universitário


22 © Análise e Projeto de Sistemas

O esquema revela, também, o que é enfatizado nas fases de análise (investigação do pro-
blema) e projeto (solução lógica), além de apresentar, também, os modelos que são criados nas
fases de análise e projeto, tanto para a Análise Essencial (modelo ambiental e modelo compor-
tamental) quanto para a orientação a objetos (modelo de classes, modelo de estados e modelo
de interações).
Por fim, pelo esquema você percebe que uma atenção deve ser dada ao processo iterati-
vo/incremental de desenvolvimento de software.
O Esquema dos Conceitos-chave é mais um dos recursos de aprendizagem que vem se
somar àqueles disponíveis no ambiente virtual, por meio de suas ferramentas interativas, bem
como àqueles relacionados às atividades didático-pedagógicas realizadas presencialmente no
polo. Lembre-se de que você, aluno EaD, deve valer-se da sua autonomia na construção de seu
próprio conhecimento.

Questões Autoavaliativas
No final de cada unidade, você encontrará algumas questões autoavaliativas sobre os con-
teúdos ali tratados, as quais podem ser de múltipla escolha, abertas objetivas ou abertas dis-
sertativas.
Responder, discutir e comentar essas questões, bem como relacioná-las com a prática de
Análise e Projeto de Sistemas pode ser uma forma de você avaliar o seu conhecimento. Assim,
mediante a resolução de questões pertinentes ao assunto tratado, você estará se preparando
para a avaliação final, que será dissertativa. Além disso, essa é uma maneira privilegiada de você
testar seus conhecimentos e adquirir uma formação sólida para a sua prática profissional.
Você encontrará, ainda, no final de cada unidade, um gabarito, que lhe permitirá conferir
as suas respostas sobre as questões autoavaliativas de múltipla escolha.

As questões de múltipla escolha são as que têm como resposta apenas uma alternativa correta. Por
sua vez, entendem-se por questões abertas objetivas as que se referem aos conteúdos matemáticos
ou àqueles que exigem uma resposta determinada, inalterada. Já as questões abertas dissertativas
obtêm por resposta uma interpretação pessoal sobre o tema tratado; por isso, normalmente, não há
nada relacionado a elas no item Gabarito. Você pode comentar suas respostas com o seu tutor ou com
seus colegas de turma.

Bibliografia Básica
É fundamental que você use a Bibliografia Básica em seus estudos, mas não se prenda só
a ela. Consulte, também, as bibliografias complementares.

Figuras (ilustrações, quadros...)


Neste material instrucional, as ilustrações fazem parte integrante dos conteúdos, ou seja,
elas não são meramente ilustrativas, pois esquematizam e resumem conteúdos explicitados no
texto. Não deixe de observar a relação dessas figuras com os conteúdos, pois relacionar aquilo
que está no campo visual com o conceitual faz parte de uma boa formação intelectual.

Dicas (motivacionais)
O estudo deste Caderno de Referência de Conteúdo convida você a olhar, de forma mais
apurada, a Educação como processo de emancipação do ser humano. É importante que você
se atente às explicações teóricas, práticas e científicas que estão presentes nos meios de co-
© Caderno de Referência de Conteúdo 23

municação, bem como partilhe suas descobertas com seus colegas, pois, ao compartilhar com
outras pessoas aquilo que você observa, permite-se descobrir algo que ainda não se conhece,
aprendendo a ver e a notar o que não havia sido percebido antes. Observar é, portanto, uma
capacidade que nos impele à maturidade.
Você, como aluno dos cursos de Graduação na modalidade EaD, necessita de uma forma-
ção conceitual sólida e consistente. Para isso, você contará com a ajuda do tutor a distância, do
tutor presencial e, sobretudo, da interação com seus colegas. Sugerimos, pois, que organize bem
o seu tempo e realize as atividades nas datas estipuladas.
É importante, ainda, que você anote as suas reflexões em seu caderno ou no Bloco de
Anotações, pois, no futuro, elas poderão ser utilizadas na elaboração de sua monografia ou de
produções científicas.
Leia os livros da bibliografia indicada, para que você amplie seus horizontes teóricos. Co-
teje-os com o material didático, discuta a unidade com seus colegas e com o tutor e assista às
videoaulas.
No final de cada unidade, você encontrará algumas questões autoavaliativas, que são im-
portantes para a sua análise sobre os conteúdos desenvolvidos e para saber se estes foram
significativos para sua formação. Indague, reflita, conteste e construa resenhas, pois esses pro-
cedimentos serão importantes para o seu amadurecimento intelectual.
Lembre-se de que o segredo do sucesso em um curso na modalidade a distância é partici-
par, ou seja, interagir, procurando sempre cooperar e colaborar com seus colegas e tutores.
Caso precise de auxílio sobre algum assunto relacionado a este Caderno de Referência de
Conteúdo, entre em contato com seu tutor. Ele estará pronto para ajudar você.

3. REFERÊNCIA BIBLIOGRÁFICA
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Addison-Wesley, 2007.

Claretiano - Centro Universitário


Claretiano - Centro Universitário
EAD
Visão Geral da Análise
e Projeto de Sistemas

1. OBJETIVOS
• Conhecer a NBR ISO/IEC 12207 e identificar as atividades e tarefas de desenvolvimento
do software segundo esta norma.
• Definir o ciclo de vida do software.
• Definir os principais conceitos envolvidos em análise e projeto de software.
• Conhecer as diferentes abordagens de análise para projetos de software (estruturada
e orientada a objetos).
• Analisar os modelos e apresentar as razões para se modelar sistemas.
• Conhecer os três modelos pilares da modelagem de sistemas orientados a objetos.
• Conhecer a rotina de atividades do profissional que realiza análise e projeto de siste-
mas.

2. CONTEÚDOS
• Introdução ao processo de desenvolvimento do software.
• NBR ISO/IEC 12207.
• Ciclo de vida do software Clássico.
• Conceitos fundamentais de análise e projeto de sistemas: abstração, refinamento e
modularidade.
• Análise e modelagem de software.
• Conceito de modelo e a importância da modelagem de sistemas.
26 © Análise e Projeto de Sistemas

• Abordagem de análise voltada a processos e transações.


• Abordagem de análise orientada a objetos.
• Etapas do desenvolvimento de software orientado a objetos.
• Apresentação e características dos três modelos principais na modelagem de sistemas
orientados a objetos.
• O perfil do profissional que realiza análise e projeto do software.

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Tenha sempre à mão o significado dos conceitos explicitados no Glossário e suas liga-
ções pelo Esquema de Conceitos-chave. Isso poderá facilitar sua aprendizagem e seu
desempenho.
2) Assegure-se de compreender bem as etapas que compõem o ciclo de vida de um
sistema, independentemente do modelo de processo que será utilizado no desenvol-
vimento do software.
3) Certifique-se de compreender bem as duas abordagens para desenvolvimento de
software: análise essencial e análise orientada a objetos.
4) Atente-se para a importância de modelar sistemas de software. Grande parte do su-
cesso de um sistema após sua implantação está na boa compreensão de seus requisi-
tos, e na criação de modelos que retratem o sistema.
5) Nesta unidade, iniciaremos nosso estudo em análise e projeto de software. Conhece-
remos a organização do processo de produção e o trabalho do Analista de Sistemas
nesse contexto. Portanto, fique atento ao conteúdo que será estudado e, caso tenha
dúvidas, entre em contato com seus colegas de curso ou seu tutor.
6) Você estudará a NBR ISO/IEC 12207. Pesquise mais sobre essa norma para aprofundar
seus conhecimentos. Entretanto, em Engenharia de Software, você verá os outros pro-
cessos dessa norma, bem como os conceitos de ciclo de vida do software, além disso,
conhecerá os diversos modelos que organizam o desenvolvimento do software de mo-
dos diferentes.
7) A NBR ISO/IEC 12207 define, detalhadamente, os procedimentos de execução das ta-
refas, ao mesmo tempo em que permite sua adaptação para projetos de software de
qualquer natureza. Ela também especifica os cuidados que se deve ter na elaboração
de diversas atividades.
8) A NBR ISO/IEC 12207 distingue a nomenclatura de "desenho", em vez de "projeto",
para as atividades de especificação do software. O conceito de "projeto" é considerado
o empreendimento concluído para desenvolver um software. "Desenho" é o conjunto
de atividades que buscam definir, com exatidão, como o software será construído.
9) Sugerimos que conheça as áreas da Engenharia de Software, acessando o site indica-
do do SWEBOK, <www.swebok.org>. Pesquise, também, na obra de Pressman (2006),
cuja referência completa está disponível no final deste material, no tópico Referências
Bibliográficas.
10) Depois de estudar o conceito de abstração, imagine um problema relacionado a as-
suntos do dia a dia. Tente abstrair apenas os aspectos relevantes do problema pro-
posto. Será que os aspectos selecionados por você o levarão a encontrar uma solução
para o problema? Reflita a respeito.
11) Não nos deteremos ao estudo detalhado da evolução das técnicas de análise. Todavia,
é interessante que você as conheça. Realize algumas pesquisas, para esclarecer dúvi-
das que possam surgir sobre este assunto e, também, para conhecer mais sobre ele.
© U1 – Visão Geral da Análise e Projeto de Sistemas 27

12) A primeira linguagem orientada a objetos foi a Smalltalk, desenvolvida no final da dé-
cada de 1970. No entanto, sua utilização foi muito restrita, e outras linguagens orien-
tadas a objetos foram propostas. A linguagem de programação orientada a objetos
mais conhecida é C++ (lê-se "C" plus plus). Inicialmente, C++ era chamada "C com
classes", e seu nome foi alterado para C++ em 1983. Algumas das características de
C++ foram baseadas na linguagem Simula67, que embora não fosse exatamente uma
linguagem orientada a objetos, implementava diversos dos conceitos que são funda-
mentais para a programação orientada a objetos.
13) Lembre-se de que, no paradigma da orientação a objetos, o desenvolvimento de um
sistema acontece em torno de objetos (conceitos), e não em torno de funções ou
processos.

4. INTRODUÇÃO À UNIDADE
O objetivo principal do estudo desta primeira unidade é ajudar você a compreender como
podemos utilizar métodos, procedimentos, técnicas e ferramentas para organizar as atividades
de análise e projeto, melhorando, assim, o processo de desenvolvimento e, consequentemente,
a qualidade final do software.
Os objetivos a serem alcançados, nesta unidade, fundamentam-se na compreensão do ci-
clo de vida do software e no relacionamento das atividades e tarefas realizadas pelo profissional
que executa o papel de Analista de Sistemas.
É fundamental que você compreenda, ao longo dos estudos apresentados, que as ativida-
des e tarefas no âmbito da análise e projeto de sistemas não têm um fim em si mesmas, mas se
integram com diversas outras atividades de apoio e atividades gerenciais.
O profissional que trabalha com esse conjunto de habilidades e competências usualmente
recebe o nome de Analista de Sistemas, nomenclatura que se tornou comum para o curso supe-
rior em informática, denominado Análise de Sistemas.
Mas qual é o perfil desse profissional?
O perfil desse profissional não é claramente delimitado e atualmente discute-se a forma-
ção em análise e projeto de sistemas como uma das habilidades e competências da formação
em Engenharia de Software, uma disciplina, geralmente, comum a todas as grandes áreas de
formação da Computação, que são: Engenharia de Computação, Ciência da Computação, Siste-
mas de Informação e Licenciatura em Computação.
Todos os profissionais formados nessas áreas devem possuir habilidades e competências
que possibilitem o desenvolvimento disciplinado (análise, projeto, programação, teste e vali-
dação) do software, muito embora esses cursos tendam a enfatizar em maior ou menor grau,
essas habilidades e competências. As especificidades da área de atuação de cada profissional
direcionarão as características do software desenvolvido, porém as atividades e as tarefas serão
as mesmas.
É importante ressaltar que quando nos referimos ao Analista de Sistemas, estamos nos
referindo a apenas um dos papéis necessários aos projetos de software, e não a um profissional
formado em um determinado curso, ou seja, o Analista de Sistemas pode ter qualquer uma das
formações citadas anteriormente. Exemplos de outros papéis possíveis em projetos do software
são: gerente de projeto, programador, testador, documentador e homologador, entre outros.
Esse é o caso do profissional formado em Licenciatura em Computação, que poderá utili-
zar as habilidades e competências adquiridas no curso para desenvolver, por exemplo, software
Claretiano - Centro Universitário
28 © Análise e Projeto de Sistemas

para gestão educacional, capacitação continuada de docentes, formação e avaliação de profes-


sores, ensino de Matemática, ensino de Língua Portuguesa e de Ciências, bem como o trabalho
com questões de interdisciplinaridade (com o auxílio do computador no desenvolvimento de
software), recuperação do aprendizado etc.

Problematizando o tema
Você deve ter contato com diversos tipos de aplicações em software no seu cotidiano. Por
acaso, você já parou para se questionar sobre como um software é construído? Será que a pro-
gramação é a única atividade a ser realizada? Afinal, o que é análise de sistemas?
Nos primórdios da computação, o grande desafio era desenvolver tecnologias de hardware.
O tamanho, o desempenho, o consumo de recursos e especialmente o custo dos equipamentos
eram grandes limitadores da inserção da tecnologia nos segmentos da sociedade. Com o passar
do tempo, o desafio migrou do hardware para o software. O desenvolvimento proporcionado pela
miniaturização de componentes tornou o uso da informática muito mais comum do que se imagi-
nava há pouco tempo.
Considerando todas essas mudanças, a meta das empresas, atualmente, é reduzir o custo
do desenvolvimento do software e, ao mesmo tempo, melhorar a sua qualidade. Diante desse
desafio, o papel do Analista de Sistemas é fundamental.
Todos os aspectos da produção de software, tais como os processos de desenvolvimento, as
atividades de gerenciamento de projeto, o uso e desenvolvimento de métodos, técnicas e ferramen-
tas que apoiam a produção de software, são de responsabilidade da Engenharia de Software.
Bons estudos!

5. INTRODUÇÃO AO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE


A produção de software representa uma perspectiva de desenvolvimento extraordinário.
O software auxilia as empresas a atingirem objetivos complexos por meio da inovação tecnoló-
gica. Ele permite, também, maior velocidade na implementação de novos paradigmas decorren-
tes da revolução da Tecnologia da Informação em diversos segmentos da sociedade.
Mas, afinal de contas, como o software deve ser produzido para que seja utilizado com
sucesso?
O software é uma categoria de produto, e, como tal, é resultado de um processo produti-
vo. Pesquisas ao longo da história da computação apontam que cuidar do produto é importante,
mas cuidar do processo de produção é o primeiro passo para garantir a qualidade do produto.
Os esforços para melhorar os produtos e serviços culminaram na definição de várias normas e
padrões para garantir a qualidade durante o processo de desenvolvimento.
Atualmente, para garantir a qualidade do processo de desenvolvimento de software, po-
demos contar com a NBR ISO/IEC 12207, apresentada a seguir.

NBR ISO/IEC 12207


A produção de software é uma tarefa complexa e possui muitas especificidades. Assim,
várias organizações mundiais desenvolveram estudos voltados à padronização deste processo.
Uma dessas organizações, que podemos classificar como a mais importante, é a International
Organization for Standardization (ISO).
A ISO estabeleceu uma série de documentos, em forma de normas e padrões para a qua-
lidade de produto e processo, em diversas áreas. Esses documentos se tornaram mundialmente
© U1 – Visão Geral da Análise e Projeto de Sistemas 29

conhecidos como Normas ISO, e, entre eles, um conjunto chamado ISO 9000. Para complemen-
tar a aplicação da série ISO 9000 no desenvolvimento de software, foi elaborada outra norma
chamada ISO/IEC 12207, traduzida e publicada pela ABNT como NBR ISO/IEC 12207 – Processos
de ciclo de vida do software.
A NBR ISO/IEC 12207 apresenta processos agrupados em categorias, mas não define uma
ordem ou sequência para que isso ocorra. Essa norma é utilizada para nos ajudar a definir um
ciclo de vida em um projeto, e, nessa definição, indicamos a ordem de ocorrência ou execução
dos processos. A definição dos processos e a sua sequencialidade são realizadas antes das ativi-
dades de análise e projeto de sistemas, pelo gerente de projeto, no planejamento do projeto de
software. Esses assuntos também serão abordados em Engenharia de Software.
Por ora, conhecer essa norma é importante para a compreensão global das atividades do
processo de desenvolvimento de software. Na prática, o que distinguirá um ciclo de vida de outro é
a estratégia de utilização dos processos que o gerente define para um projeto, como, por exemplo,
o momento de ocorrência ou repetição de um processo específico ou mesmo se ele vai ser adota-
do. Veremos que alguns processos são indispensáveis e sempre ocorrerão, outros não, e mesmo
para os processos que sempre ocorrem, há atividades ou tarefas que podem ser excluídas.
A Norma ISO/IEC 12207 é, na realidade, uma coletânea de documentos que define, expli-
citamente, os processos envolvidos no desenvolvimento de software, que doravante chamare-
mos de "ciclo de vida". Ciclo de vida é o termo utilizado em processos produtivos para expres-
sar a ideia de que um produto ou serviço tem sua existência definida a partir de uma fase de
entendimento, na qual se busca conhecer, exatamente, o que se espera que seja desenvolvido;
prolonga-se na fase de construção, na qual são produzidas as especificações técnicas que de-
talham a solução criada para atender às necessidades dos futuros usuários e, também, na qual
o sistema é efetivamente produzido; e estende-se até a fase de implantação e manutenção, só
terminando quando há substituição ou retirada de uso desse produto.
Essas quatro fases (entendimento, construção, implantação e manutenção), que com-
põem o ciclo de vida do software, podem ser mais detalhadas. Você verá isso mais adiante.
Vale lembrar, aqui, que as fases que compõem o ciclo de vida de um sistema podem ser
apresentadas de forma mais ou menos reduzida. Considerando-se as quatro fases citadas no
início desse parágrafo, podemos entender que a análise e o projeto, que são objetos específicos
de nosso estudo, estão compreendidas na fase de construção.
O entendimento envolve a ideia do desenvolvimento de um sistema, acrescida à explo-
ração inicial que se faz sobre o mesmo, a fim de se descobrir as primeiras necessidades para o
sistema. Essa exploração torna-se mais profunda, para descobrir-se o que realmente precisa ser
feito (a solução para o sistema). Na fase da construção, determina-se como essa solução será
desenvolvida e, por meio de linguagens de programação, são escritos os programas. A fase de
implantação refere-se à instalação do sistema no cliente.
A NBR ISO/IEC 12207 organiza os processos envolvidos na produção do software em três
classes: Processos fundamentais, Processos de apoio e Processos organizacionais. Neste ma-
terial, não nos deteremos em detalhes desta norma, apenas utilizaremos em nosso estudo os
processos da classe fundamental, mais especificamente o processo de desenvolvimento.
A Figura 1 apresenta a visão geral da organização dos processos dessa norma. Nela está
disposto um conjunto de processos possíveis no ciclo de vida do software.

Claretiano - Centro Universitário


30 © Análise e Projeto de Sistemas

Processos Fundamentais Processos de Apoio

Aquisição Documentação
Fornecimento Gerência de configuração
Desenvolvimento Garantia da qualidade
Operação Verificação
Manutenção
Validação
Revisão
Auditoria
Resolução de problemas

Processos Organizacionais
Gerência Infra-estrutura
Melhoria Treinamento

Figura 1 Grupo de Processos da NBR ISO/IEC 12207.

Em projetos de software, é comum encontrar alguns processos que podemos considerar


como básicos, como é o caso do processo de Desenvolvimento. Este processo agrupa as ativida-
des de aquisição de conhecimento sobre o produto, especificação, projeto, construção e teste.
Todavia, a peculiaridade de um projeto pode demandar que processos específicos sejam acres-
centados, como é o caso do processo de Aquisição.
Outra visão importante que essa norma apresenta é a estruturação dos processos no ci-
clo de vida, conforme demonstra a Figura 2. De acordo com essa figura, um ciclo de vida é, na
realidade, uma coletânea de processos que possibilitam viabilizar a produção de um software
dentro dos parâmetros de tempo, custo e qualidade, previamente definidos. A escolha, ou me-
lhor, a composição dos processos de um ciclo de vida é usualmente realizada por um gerente de
projeto ou por um engenheiro de software.
Podemos observar na Figura 2 que os processos são conjuntos de Atividades e, por sua
vez, as Atividades são grupos de Tarefas.

Atividade 1

Processo Tarefas
1

Ciclo de Vida ...


Processo Processo
... …

Atividade N

Tarefas

Figura 2 Hierarquia dos Processos da NBR ISO/IEC 12207 – Ciclo de vida.

Atividades e tarefas do processo de desenvolvimento de acordo com a NBR ISO/IEC 12207


Em nosso estudo, vamos apresentar o processo de desenvolvimento do software definido
na NBR ISO/IEC 12207.
A primeira atividade é a Implementação do processo. As tarefas dessa atividade são,
normalmente, de competência de um gerente de projetos. Lembre-se de que as competências
indicadas no texto são apenas referências a papéis que devem ser desempenhados, e não exa-
tamente a cargos estabelecidos. Também é comum encontrar em pequenas organizações pro-
fissionais contratados que realizam diversos papéis ao mesmo tempo.
© U1 – Visão Geral da Análise e Projeto de Sistemas 31

Ao iniciar um novo projeto, o gerente deve realizar um estudo preliminar das especifici-
dades do software e das restrições identificadas para compor um ciclo de vida adequado ao
projeto, com processos específicos à empreita. As tarefas a serem realizadas são:
a) Definir o modelo do ciclo de vida do software. O gerente de projeto executa o plane-
jamento e uma de suas primeiras atividades é definir um ciclo de vida, adotando um
modelo padrão ou definindo um específico.
b) Documentar e controlar as saídas (informações produzidas durante as atividades).
É necessário que todas as informações levantadas sejam documentadas, revisadas e
aprovadas.
c) Selecionar as normas, ferramentas e linguagens. O gerente é responsável por selecio-
nar padrões de desenvolvimento, ferramentas de apoio – automatizadas ou não – e a
linguagem de programação.
d) Desenvolver, documentar e executar os planos de desenvolvimento. Um plano, mui-
tas vezes, composto por uma coletânea de diversos planos, deve ser produzido, revi-
sado e aprovado.
e) Assegurar que todos os produtos necessários serão entregues. O gerente deve desen-
volver meios para executar todas as tarefas e assegurar a consistência dos documen-
tos produzidos para a atividade seguinte.
A segunda atividade é a Análise dos requisitos do sistema. Podemos imaginar esta ativi-
dade como um estudo que busca compreender o problema em sua amplitude, mas não neces-
sariamente em sua profundidade. Esta atividade procura estabelecer a proposta de uma solução
geral, envolvendo questões como a tecnologia e os recursos humanos, além do software em si.
As informações levantadas nesta fase definem os procedimentos de planejamento e po-
dem influenciar na escolha de tecnologias para o projeto, tais como: o Sistema Gerenciador de
Banco de Dados (SGBD), o Sistema Operacional (SO) das máquinas servidoras e das máquinas
clientes, a linguagem de programação, o treinamento dos desenvolvedores, testes etc.
Essa atividade pode ser desenvolvida em paralelo com a atividade anterior e é, usualmen-
te, de competência de um Analista de Sistemas e de um Analista de Negócios. As tarefas a serem
realizadas são:
• especificar os requisitos do sistema;
• avaliar os requisitos de acordo com os critérios da norma.
A terceira atividade no processo de desenvolvimento do software é o Desenho da arqui-
tetura do sistema. Os requisitos do sistema levantados previamente orientam o desenho da
arquitetura de um software.
A arquitetura de um software oferece-nos a visão de como o problema está estruturado
em problemas menores. Como veremos no decorrer deste Caderno de Referência de Conteúdo,
ao estudarmos um problema complexo, é melhor quebrá-lo em partes menores, mais fáceis de
serem compreendidas. Um sistema pode ser, na realidade, composto por subsistemas, e alguns
desses, às vezes, também podem ser decompostos.
Todavia, essas partes são organizadas, e devem possuir uma hierarquia, que precisa ser
definida nessa atividade. O desenho da arquitetura é, usualmente, de competência de um Ana-
lista de Sistemas. As tarefas a serem realizadas nesta atividade são:
• estabelecer uma arquitetura de alto nível;
• avaliar a arquitetura de acordo com os critérios da norma. O gerente deve revisar e
aprovar a arquitetura de alto nível.

Claretiano - Centro Universitário


32 © Análise e Projeto de Sistemas

A quarta atividade é a Análise dos requisitos do software (não a confunda com a análise
dos requisitos do sistema!). Esta atividade também é de competência do Analista de Sistemas.
Trata-se do levantamento, da modelagem e da especificação das necessidades (que chamare-
mos de requisitos) dos futuros usuários do sistema. As tarefas a serem realizadas são:
• Estabelecer e documentar os requisitos do software. Os requisitos devem ser identifi-
cados, modelados, analisados e documentados.
• Avaliar os requisitos de acordo com os critérios da norma. O documento dos requisitos
deve ser revisado.
• Conduzir as revisões conjuntas. O documento dos requisitos deve ser aprovado.
A quinta atividade é o Desenho da arquitetura do software. Nesta atividade entendemos
o conceito de arquitetura como a organização global e hierárquica dos módulos que irão compor
o software. Dois pontos devem ser destacados: a elaboração da documentação preliminar do
usuário, ou seja, o manual do sistema, e a definição dos requisitos preliminares para os testes.
Observe que essas tarefas produzem, aqui, o delineamento de documentos – manual do
usuário e planos de testes – bem mais cedo que usualmente se pensa (e se faz!). As tarefas a
serem realizadas nesta atividade também são de competência de um Analista de Sistemas. Na
obra de Pressman (2006), Engenharia de Software, um estudo detalhado sobre as tarefas dessa
atividade pode ser encontrado no capítulo 10 – Engenharia de Sistemas –, e 14 – Projeto Arqui-
tetural. São elas:
a) transformar os requisitos em uma arquitetura de alto nível;
b) documentar o desenho de alto nível para as interfaces;
c) documentar o desenho de alto nível das bases de dados;
d) documentar a documentação preliminar para o utilizador;
e) documentar os requisitos preliminares para os testes;
f) avaliar a arquitetura de acordo com os critérios da norma;
g) conduzir as revisões conjuntas.
A sexta atividade é o Desenho detalhado do software. Nesta atividade, ao detalharmos
a especificação de cada um dos componentes propostos para o software, bem como as estru-
turas de dados necessárias, concentraremos grande parte do nosso esforço como Analista de
Sistemas. As tarefas dessa atividade são, em grande parte, cobertas pela técnica de Análise
Essencial, que você conhecerá neste estudo. No entanto, não serão abordados os detalhes para
a elaboração da documentação preliminar para o utilizador, que diz respeito ao manual de utili-
zação do software. Os requisitos para testes unitários e de integração são derivações diretas do
documento de requisitos produzido.
As tarefas a serem realizadas nessa atividade são:
a) documentar o desenho de cada componente;
b) documentar o desenho das interfaces;
c) documentar o desenho das bases de dados;
d) atualizar a documentação para o usuário;
e) documentar os requisitos para os testes unitários;
f) atualizar os requisitos para o teste de integração;
g) avaliar o desenho detalhado de acordo com os critérios da norma;
h) conduzir as revisões conjuntas.
© U1 – Visão Geral da Análise e Projeto de Sistemas 33

Desse modo, a maioria das tarefas, tais como testes e integrações (tanto de software quan-
to de sistema) e suporte à aceitação do software estão inseridas em um conjunto de processos
chamado verificação e validação de software. Tais conceitos são abordados em Engenharia de
Software. Na prática, os testes são usualmente realizados por uma equipe de especialistas em
testes de software.
A atividade consequente ao desenho detalhado do software é a sétima atividade: a Codi-
ficação e teste do software.
Nessa fase do processo, ocorre a codificação, que é a implementação do sistema em uma
linguagem de computador, realizada usualmente por uma equipe de programadores.
Os testes são realizados para verificar a presença de erros e o comportamento adequado
ao nível das funções e aos módulos básicos do sistema. As tarefas a serem realizadas nesta ati-
vidade são:
a) desenvolver e documentar cada unidade do software e procedimentos de teste;
b) conduzir e documentar os testes unitários;
c) atualizar a documentação para o utilizador, se necessário;
d) atualizar os requisitos para o teste de integração;
e) avaliar o código e os resultados dos testes de acordo com os critérios da norma.
A Integração do software é a oitava atividade e tem como objetivo verificar e validar a
reunião dos diferentes módulos em um produto de software homogêneo, e a interação entre
estes quando operando em conjunto. As tarefas a serem realizadas nessa atividade são:
a) desenvolver e documentar os planos de integração;
b) conduzir e documentar os testes de integração;
c) atualizar a documentação para o usuário, se necessário;
d) preparar o teste de qualificação;
e) avaliar e documentar o plano de integração de acordo com os critérios da norma;
f) conduzir revisões conjuntas.

Requisitos de qualificação_____________________________________________________
A NBR ISO/IEC 12207 estabelece que o teste de qualificação do sistema deve ser conduzido conforme os requisitos
de qualificação especificados para o sistema. De acordo com esta norma:
– Qualificação: é o processo que demonstra se uma entidade é capaz de atender os requisitos especificados.
– Requisito de qualificação: é o conjunto de critérios ou de condições que, quando atendidos, qualificam um produto
de software quanto à conformidade às suas especificações e quanto à sua utilização no seu ambiente-alvo.
– Teste de qualificação: é o teste conduzido pelo desenvolvedor e testemunhado pelo adquirente (quando apropria-
do), ou seja, o cliente acompanha os testes aplicados pelo desenvolvedor para demonstrar que o produto de software
atende às suas especificações e está pronto para utilização no seu ambiente-alvo.
___________________________________________________________________________

São etapas que compõem a atividade de Teste qualificativo do software:


• realizar o teste de qualificação e registrar os resultados produzidos;
• atualizar o material documentado do desenvolvedor;
• avaliar os documentos utilizados pelo desenvolvedor (modelos, códigos-fonte, testes,
entre outros), e registrar o resultado das avaliações;
• possibilitar a realização de auditorias e registrar os resultados produzidos;
• atualizar e preparar o produto de software para ser entregue aos processos seguintes.

Claretiano - Centro Universitário


34 © Análise e Projeto de Sistemas

Tarefas da atividade de Integração do sistema:


• realizar a integração do software, do hardware e demais componentes que fizerem
parte do sistema;
• preparar os planos de testes de integração;
• avaliar o sistema, após a sua integração, conforme os critérios da norma.
Tarefas da atividade de Teste qualificativo do sistema:
• realizar os testes de qualificação e registrar os resultados produzidos;
• avaliar o sistema, conforme os critérios da norma;
• possibilitar a realização de auditorias;
• gerar o pacote para instalação do produto.
Por último, temos a nona atividade, que é a Instalação do software e Suporte à aceitação
do software, que tem como objetivo planejar e implementar a instalação do software pronto
para ser utilizado, bem como cuidar da formação dos futuros usuários. Essas tarefas são, usual-
mente, realizadas por analistas de negócio, juntamente com pessoas especializadas em ativida-
des de verificação e validação do software.
Observe, a seguir, quais são as tarefas das atividades da Instalação do software e do Su-
porte à aceitação do software.
Tarefas da atividade de Instalação do software:
• preparar o plano de instalação do produto;
• instalar o software conforme o planejado.
Tarefas da atividade de Suporte à aceitação do software:
• oferecer suporte ao cliente quando da realização dos testes de aceitação;
• cumprir o estabelecido no contrato em relação à entrega do produto;
• fornecer suporte e treinamento, conforme o estabelecido no contrato.
Finalizamos, aqui, nossa visão geral sobre o processo de desenvolvimento do software.
Observamos os processos que podem compor o ciclo de vida de um projeto de software, funda-
mentais para o trabalho de todos os envolvidos nele. Para o cliente, a visão de que o ciclo de vida
de um software é algo complexo é importante para que ele possa compreender como o forne-
cedor poderá atingir os objetivos contratuais combinados, tais como: prazo, custo e qualidade.
Entretanto, para os envolvidos na produção, esta visão proporciona a compreensão da interde-
pendência das atividades e de como o trabalho de cada um pode contribuir para o sucesso do
grupo e, consequentemente, do projeto.

O ciclo de vida Clássico


A NBR ISO/IEC 12207 define detalhadamente os procedimentos de execução das tarefas,
mas não detalha a sua sequencialidade. A resposta para isso é simples: trata-se de um conjunto
das melhores práticas que devem ser instanciadas, ou seja, ao iniciar um projeto, selecionam-se
e adaptam-se as práticas mais adequadas e, então, define-se a sequência de execução.
Entretanto, ao longo da história surgiram propostas de ciclos de vida que poderiam ser uti-
lizados em determinadas categorias de projetos. O ciclo de vida Clássico foi o primeiro deles.
O modelo apresentado a seguir, na Figura 3, é conhecido como ciclo de vida Clássico, tam-
bém denominado como Linear, ou ainda, Cascata. Ele é sugerido quando o projeto apresenta
© U1 – Visão Geral da Análise e Projeto de Sistemas 35

características que indicam que os requisitos serão fáceis de serem compreendidos e que o
projeto poderá ser realizado sem grandes complicações. Usualmente, os projetos que utilizam o
ciclo de vida Clássico são de pequeno porte ou, projetos de manutenção em algum software que
utilizam tecnologias e procedimentos bem conhecidos pela equipe de desenvolvimento.

Concepção

Análise

Projeto

Implementação

Teste

Implantação

Manutenção

Figura 3 Modelo de processo em cascata.

A principal característica deste modelo é a sequencialidade das atividades. Observe que a


figura lembra uma escada. Pense nessa escada como um conjunto de rochas, nas quais a água
deve fluir, ou seja, uma cascata. Em uma cascata, a água não volta para cima, mas vai batendo
na rocha de baixo à medida que cai. Isso indica que é necessário que uma atividade seja com-
pletamente realizada para que a outra seja iniciada.
Tradicionalmente, este modelo é utilizado para ajudar o aluno a compreender a integra-
ção e sequencialidade de atividades em projetos de software.
Mas não se engane: embora pareça (e é) óbvio que em todos os desenvolvimentos de
software são realizadas as atividades descritas no modelo, a maioria dos projetos não segue
rigidamente o preceito da sequencialidade e, frequentemente, necessita de algum tipo de volta
à fase anterior. Projetos de natureza complexa e projetos de grande porte geralmente têm essa
demanda.
Por isso, surgiram outros modelos em Engenharia de Software. É importante ressaltar que
toda empresa, grande ou pequena, utiliza um processo para desenvolver software. É comum,
também, que o gerente do projeto ou, o profissional responsável pela definição do modelo de
ciclo de vida, o defina baseado em suas próprias estratégias quanto ao uso dos processos que
você conheceu na NBR ISO/IEC 12207, mesmo que, muitas vezes, o profissional desconheça
esta norma. Uma estratégia para grandes projetos poderia ser, por exemplo, se ele fosse anali-
sado completamente e, então, quebrado em grandes funcionalidades. Posteriormente, seriam
desenvolvidas as atividades de projeto, codificação, teste e validação final para cada grande fun-
cionalidade. As funcionalidades seriam sequencialmente desenvolvidas, e o software acabaria
sendo entregue em partes, não de uma só vez.
O ciclo de vida Clássico apresenta cinco atividades de desenvolvimento e a fase de manu-
tenção.

Claretiano - Centro Universitário


36 © Análise e Projeto de Sistemas

Observe as fases do ciclo de vida Clássico na Figura 3. Os objetivos gerais de cada uma das
atividades do ciclo de vida Clássico (PRESSMAN, 2006) são apresentados a seguir. Veja que há
uma correspondência lógica com os processos apresentados na NBR ISO/IEC 12207.
1) Análise e engenharia de sistemas – envolve a coleta de requisitos do sistema com
pouca análise e projeto de alto nível. Esta visão é essencial quando o software faz in-
terface com outros elementos (hardware, pessoas e banco de dados).
2) Análise de requisitos de software – o processo de coleta dos requisitos é realizado,
com ênfase, nas necessidades exigidas para o software. Deve-se compreender o do-
mínio da informação, a função, o desempenho e as interfaces exigidas. Essa etapa
deve ser realizada juntamente com o cliente.
3) Projeto – trata-se da representação dos requisitos do software por meio de um con-
junto de artefatos (normalmente, os modelos), que ajudam a avaliar a qualidade do
produto a ser desenvolvido, antes que o software seja codificado.
4) Codificação – tradução das representações do projeto para uma linguagem de compu-
tador, resultando em instruções executáveis pelo computador.
5) Testes – são procedimentos realizados com o software produzido, com o objetivo de
garantir que o mesmo não contenha erros. Os planos de teste são elaborados para
que cada instrução de programa seja testada, e que os resultados produzidos pelo
software sejam os esperados.
6) Manutenção – pode se tornar necessária à medida que mudanças nos requisitos do
sistema ocorrem, ou mesmo mudanças de natureza externa, mas que podem afetá-lo.
As causas das mudanças são: erros, adaptação do software para acomodar mudanças
em seu ambiente externo e exigência do cliente para acréscimos funcionais e de de-
sempenho.

6. CONCEITOS FUNDAMENTAIS DE ANÁLISE E PROJETO DE SISTEMAS: ABS-


TRAÇÃO, REFINAMENTO E MODULARIDADE
Para compreendermos melhor a dimensão do trabalho do Analista de Sistemas, vamos
estudar alguns dos principais termos envolvidos. É importante, neste momento, parar um pouco
para refletir sobre o seu significado. Entretanto, é recomendável que você volte a esses concei-
tos depois de concluir seus estudos neste Caderno de Referência de Conteúdo. Será interessante
comparar o significado desses conceitos com os estudos desenvolvidos nas próximas unidades.

Análise
Vejamos as definições que o dicionário Houaiss (2008) nos apresenta para o termo análise:
• Separação de um todo em seus elementos ou partes componentes. Exemplo: análise
de uma substância.
• Estudo pormenorizado de cada parte de um todo, para conhecer melhor sua natureza,
suas funções, relações, causas etc. Exemplo: análise dos dados de uma pesquisa de
opinião.
• Exame, processo ou método com que se descreve, caracteriza e compreende algo (um
texto, uma obra de arte etc.), para proporcionar uma avaliação crítica do mesmo.
A definição do dicionário Houaiss é muito adequada ao contexto do nosso estudo. Por-
tanto, o trabalho de análise é desenvolver estudos que geralmente partem de problemas com-
plexos, na forma de sistemas, e que são mais bem compreendidos quando são separados em
partes menores.
© U1 – Visão Geral da Análise e Projeto de Sistemas 37

Uma vez separadas, cada uma das partes ou componentes são estudadas para que sejam
conhecidas as suas funções e inter-relacionamentos. Essa estratégia diz respeito aos conceitos
de abstração, refinamento e modularidade. Ao final deste estudo, o analista deve produzir um
relato descritivo da compreensão do problema.

Abstração
Ao abstrair, o Analista de Sistemas ignora aspectos não relevantes para a solução do pro-
blema em que se está trabalhando a fim de concentrar-se nos aspectos mais importantes.

Refinamento
O refinamento é uma estratégia de decomposição, passo a passo, em níveis de detalhes
procedimentais cada vez menores, muito utilizada na elaboração de algoritmos de linguagens
de programação.
Um sistema pode ser visto como um conjunto de funções. Cada função é abstraída (iso-
lada) e, então, refinada, para que se conheçam suas subfunções e, assim, sucessivamente, até
que seja possível expressar uma função em alguma linguagem de programação. De acordo com
Pressman (2006), cada passo do processo de software é um refinamento no nível de abstração
da solução do problema.

Modularidade
A modularidade acontece em decorrência do refinamento. Durante o refinamento, o
software é dividido em funções que, na realidade, são partes ou componentes, que serão
nomeados e integrados para satisfazer os requisitos do problema.
Você já parou para pensar se um edifício com vários andares fosse construído de uma vez,
como um só bloco? Essa técnica pode até ser possível em construções muito pequenas, mas é
totalmente inviável nas grandes e complexas construções.
Embora façamos essa analogia, construir um software não é construir edificações, e as
coisas são mais complexas pelas características intrínsecas ao software. Um software composto
de um único módulo é muito difícil de ser compreendido pelo analista e, posteriormente, tam-
bém, é difícil o gerenciamento da sua construção. Mais difícil ainda é realizar as atividades de
manutenção.
A meta do trabalho de análise é identificar O QUE deve ser feito. Os estágios da análise de
sistemas, segundo Pressman (2006), envolvem determinar:
• As necessidades específicas de informações: os requisitos do software;
• As funções de processamento de informações requeridas por cada atividade do siste-
ma (entrada, processamento, saída, armazenamento e controle).
O processo de desenho do software ocorre em função do relato produzido na análise. Por
meio das tarefas realizadas nesta atividade, uma especificação de uma solução informatizada
proposta para o problema é produzida.
Vale ressaltar que o trabalho de engenharia realizado na análise não é pura e simples-
mente a produção de uma solução, mas sim a melhor solução encontrada, ou, ainda, a mais
adequada. Portanto, durante os estudos que o analista realiza, possibilidades são confrontadas
e viabilidades devem ser questionadas.

Claretiano - Centro Universitário


38 © Análise e Projeto de Sistemas

A meta do trabalho de desenho é identificar como fazer o sistema.


Os estágios de projeto de sistemas, segundo Pressman (2006), envolvem desenvolver:
a) O projeto arquitetural do sistema, que tem como meta produzir um modelo conceitu-
al para o sistema, decomposto em módulos;
b) O projeto de interface, que tem como meta produzir uma especificação da interface
de comunicação para cada módulo;
c) O projeto detalhado, que tem como meta especificar cada módulo individualmente e,
possivelmente, traduzi-los para pseudocódigo;
d) O projeto da estrutura de dados, que tem como meta transformar o modelo do do-
mínio de informação, criado durante a análise, nas estruturas de dados que vão ser
necessárias para implementar o software.
É importante destacar que a análise e o projeto de sistemas, embora usualmente ditas
e compreendidas como uma só atividade, são, na realidade, duas atividades da engenharia de
software. Basicamente, engenharia é um processo cujas atividades típicas de desenvolvimento
de um produto são a análise, o projeto, a construção, a verificação e a gestão de elementos téc-
nicos e, também, humanos.
Pressman (2006) ilustra melhor essa definição, afirmando que a engenharia de software é
uma tecnologia em camadas. O objetivo da integração dessas camadas é o foco na qualidade. A
camada mais externa é o processo, um conjunto de atividades aplicáveis a um projeto de software
que mantém unidas as outras camadas. A segunda camada são os métodos utilizados no processo.
Eles fornecem a técnica de como se fazer para construir um software. A camada mais interna são
as ferramentas, que fornecem apoio para o processo e para os métodos.

7. IMPORTÂNCIA DA MODELAGEM DE SISTEMAS


O desenvolvimento de sistemas é uma tarefa complexa, que envolve um conjunto de ativi-
dades relacionadas à produção de um produto de software. Para isso, a Engenharia de Software
apresenta diferentes abordagens de desenvolvimento de processos. Embora os processos para
a produção de sistemas sejam diferentes, todos eles apresentam atividades comuns ao desen-
volvimento, tais como: especificação, desenvolvimento, validação e evolução do software.
Uma das principais tarefas de um Analista de Sistemas, ao se debruçar sobre um novo
projeto de software, é realizar a modelagem de componentes, dados ou comportamentos, abs-
traídos do problema.
Você sabe por que devemos modelar um sistema?
A resposta é simples: construímos modelos para melhor compreender o sistema que es-
tamos desenvolvendo.
Veja como o dicionário Houaiss (2008) conceitua modelo: "exemplo dado por uma pessoa,
uma coisa, que possui determinadas características em mais alto grau".
O objetivo da produção de modelos em um projeto de software é possibilitar a construção
de softwares confiáveis, de fácil entendimento e de manutenção por parte dos desenvolvedores.
A vantagem em se utilizar modelos é que eles podem proporcionar uma visão panorâmica
do sistema, como também planos detalhados, de forma que os aspectos particulares do proble-
ma modelado possam ser estudados.
© U1 – Visão Geral da Análise e Projeto de Sistemas 39

Segundo Booch et al. (2000), a modelagem de um sistema torna possível alcançar quatro
objetivos:
a) Os modelos ajudam a visualizar como o sistema é ou como desejamos que ele fosse.
b) Os modelos permitem especificar a estrutura ou o comportamento de um sistema.
c) Os modelos proporcionam um guia para a construção do sistema.
d) Os modelos documentam as decisões tomadas.
De maneira geral, os modelos são criados por profissionais de diferentes áreas, com o
objetivo de experimentar algo que ainda não foi criado, mas que traz em si as características
daquele produto que se pretende criar.
Para entender melhor a importância da criação dos modelos, faremos uma comparação
com a construção de uma casa ou de um avião. A complexidade desses sistemas diminui a partir
do momento em que os modelos são construídos antes do produto final, pois o modelo é uma
representação daquilo que se quer construir realmente. Ninguém, por exemplo, começaria a
construção de uma casa antes de desenvolver a sua planta; ou, então, a construção de um edi-
fício sem a criação de uma maquete.
Para Blaha e Rumbaugh (2006), a criação de modelos no desenvolvimento de sistemas de
software tem algumas finalidades, tais como:
a) Testar uma entidade física antes de construí-la. Os modelos são mais baratos e trazem
informações sobre o produto que se quer construir, antes mesmo que eles estejam
prontos.
b) Permitir a comunicação com os clientes. Os modelos são criados também com o obje-
tivo de serem mostrados ao cliente, de modo que "visualize" o produto antes de seu
desenvolvimento.
c) Visualizar os modelos. Permite que modificações sejam realizadas antes do desenvol-
vimento do produto.
d) Reduzir a complexidade. É um dos motivos mais importantes para se fazer modela-
gem. O modelo reúne menor número de aspectos relevantes a serem analisados.
Para que um modelo cumpra com seus propósitos, ele deve destacar os aspectos relevan-
tes do problema e omitir os irrelevantes. A presença de detalhes desnecessários pode levar a
um desvio daquilo que realmente interessa à solução do problema.

Tipos de Modelagem
Apenas para você relembrar, a Engenharia de Software apresenta vários modelos para o
processo de desenvolvimento de sistemas. Esses modelos serão estudados posteriormente, no
módulo de Engenharia de Software.
No entanto, independentemente do modelo utilizado, qualquer sistema bem planejado
deve seguir uma metodologia de desenvolvimento. Essa prática tem como objetivo organizar e
padronizar o desenvolvimento de sistemas, além de diminuir a complexidade associada a essa
tarefa.
Uma coisa é certa: não há o melhor processo de desenvolvimento. O que existe é um con-
junto de características específicas a cada sistema, que podem fazer com que um ou outro pro-
cesso de desenvolvimento seja mais adequado a ele. Por isso, é comum observarmos sistemas
desenvolvidos não apenas com a utilização de uma metodologia, mas com duas ou mais. São as
chamadas metodologias híbridas para desenvolvimento.
Há duas maneiras que são as mais comuns de modelagem de sistema, a saber:

Claretiano - Centro Universitário


40 © Análise e Projeto de Sistemas

• A modelagem baseada em programação estruturada tradicional, ou análise e projeto


estruturados.
• A modelagem baseada no paradigma da linguagem Orientada a Objetos, ou análise e
projeto orientados a objetos.
O desenvolvimento de software baseado em alguma Linguagem de Programação Estru-
turada, como a linguagem Pascal, por exemplo, utiliza como bloco principal de construção, fun-
ções e procedimentos (processos) que interagem entre si.
Um dos pontos frágeis desta abordagem de desenvolvimento é que, por uma série de ra-
zões, à medida que o software sofre mudanças ao longo do tempo ou aumenta de tamanho com
relação à de programação de linhas de código, aumenta, também, o trabalho de manutenção.
Por sua vez, o desenvolvimento de software baseado em alguma linguagem Orientada a
Objetos, como a linguagem Java, por exemplo, utiliza como bloco principal de construção uma
classe e os seus objetos.
A principal vantagem desta tecnologia é que os dados (leia-se atributos) e os processos
(leia-se métodos) são embutidos nas classes. Essa estratégia facilita a manutenção dos objetos
no futuro, além de proporcionar a reutilização dos objetos em outros sistemas.
Veja, a seguir, uma explicação detalhada dos dois tipos de modelagens de sistemas.
Α abordagem da análise voltada a processos e transações foi considerada, antes do sur-
gimento da abordagem da orientação a objetos, como sendo a mais popular. Ela é baseada na
decomposição do sistema em funções e processos, organizados de maneira hierárquica em pro-
cessos e subprocessos.
Observa-se, nessa abordagem, uma evolução relacionada ao uso das ferramentas por ela
utilizadas. É possível dividir as técnicas da abordagem da análise em três fases, as quais serão
detalhadas a seguir:
1) Análise tradicional: contemplava apenas a perspectiva funcional do sistema, e utiliza-
va, como ferramentas, textos e fluxogramas.
2) Análise estruturada: contemplava, além da perspectiva funcional do sistema, a dos
dados. E, evoluiu no uso de ferramentas, pois incorporou a utilização do diagrama
de fluxo de dados (DFD), diagrama de estrutura de dados, as miniespecificações e o
dicionário de dados.
3) Análise essencial: considerada a máxima evolução dessa abordagem, que abrange
além das duas perspectivas abordadas na fase anterior, também a perspectiva de con-
trole, ou seja, aquela que modela o comportamento do sistema, por meio dos estados
válidos para o mesmo. Além das ferramentas utilizadas na fase anterior, também são
utilizados para a modelagem do sistema: tabela de eventos e diagrama de transição
de estados.
Já na abordagem da análise e projeto orientados a objetos, a ênfase está na decompo-
sição do sistema em objetos, também chamados de conceitos. Isso significa que é importante,
nessa abordagem, a identificação dos objetos (ou conceitos) no domínio do problema, levando
o desenvolvedor a refletir, de forma mais profunda, sobre o que cada objeto representa.
A modelagem desenvolvida com essa abordagem envolve o uso de vários diagramas (Dia-
grama de Casos de Uso, Diagrama de Classes, Diagrama de Sequência, Diagrama de Estados,
Diagrama de Atividades, entre outros), de forma que cada um deles permita visualizações das
diferentes perspectivas do sistema. A UML (Unified Modeling Language) é uma linguagem de
modelagem para sistemas orientados a objetos, e incorpora esses diagramas. Uma das grandes
© U1 – Visão Geral da Análise e Projeto de Sistemas 41

vantagens da utilização desse paradigma de desenvolvimento de software é a reutilização dos


projetos e códigos em novos projetos, além da possibilidade de compartilhamento de informa-
ções.
Sabemos que a palavra escrita é um dos veículos mais importantes de comunicação.
Mas esse veículo não é, necessariamente, o mais adequado para representar os requisitos do
software. Dessa forma, a modelagem da análise utiliza uma combinação de formas textuais e
diagramáticas para apresentar os requisitos nas dimensões estruturais, funcionais e compor-
tamentais.
A modelagem tem sido utilizada com sucesso em diversas outras áreas do conhecimento,
especialmente nas engenharias. Modelos são abstrações do mundo real. O descarte de carac-
terísticas não importantes ao domínio do problema pode trazer limitações na compreensão do
modelo, constituindo, assim, uma limitação, mas esse é um risco que devemos correr.
Ao longo da história da Computação, os profissionais perceberam a necessidade de se re-
alizar modelagens para melhor compreender os problemas que estudavam. Desse modo, foram
surgindo diversas propostas de estudiosos da engenharia do software.
Várias propostas tratavam de aspectos particulares da análise de sistemas, tais como: a
modelagem da estrutura de dados, o estudo dos processos e o fluxo de dados entre eles, a
modelagem dos estados possíveis de um sistema etc., propondo notações que acabaram se
tornando padrões.
Essas propostas, posteriormente consideradas ferramentas de análise, foram reunidas em
uma técnica que passou a ser conhecida como Análise Estruturada de Sistemas. Essa técnica
teve grande influência das ideias da programação estruturada, que propunha a quebra dos pro-
gramas monolíticos em partes menores: funções e procedimentos.
Os trabalhos mais importantes nessa área são: Gane e Sarson (1983), DeMarco (1989),
Yourdon (1990), e McMenamim e Palmer (1991).
Observando o Quadro 1, você terá uma visão geral da evolução histórica das técnicas e
ferramentas de análise, agregadas ao longo do tempo. A visualização do quadro das propostas,
a seguir, será fundamental para você iniciar seus estudos na técnica da Análise Essencial.
A Análise Tradicional é o conjunto de ferramentas utilizadas antes do surgimento da Análise
Estruturada, que consolidou o conhecimento de diversas ferramentas da engenharia de software.
A Análise Essencial é a abordagem mais completa desse conjunto de conhecimentos, pois conside-
ra três perspectivas: funções, dados e controles.

Quadro 1 Evolução histórica das técnicas de análise.


TÉCNICAS PERSPECTIVA FERRAMENTAS
texto;
Análise tradicional Funcional
fluxograma.
diagrama de fluxo de dados;
diagrama de estrutura de dados;
Funcional
Análise estruturada miniespecificações;
Dados
normalização de dados;
dicionário de dados.

Claretiano - Centro Universitário


42 © Análise e Projeto de Sistemas

TÉCNICAS PERSPECTIVA FERRAMENTAS


tabela de eventos;
diagrama de fluxo de dados;
diagrama de entidade-relacionamento;
Funcional
diagrama de estrutura de dados;
Análise essencial Dados
normalização de dados;
Controle
dicionário de dados;
miniespecificações;
diagrama de transição de estados.
Fonte: Pompilho (2002, p. 15).

A abordagem da análise orientada a objetos


De acordo com estudos realizados, pode-se afirmar que há tempos a indústria da infor-
mática pesquisa novas propostas tecnológicas, numa tentativa de minimizar as dificuldades en-
contradas no desenvolvimento de softwares e de sua manutenção, tentando manter, acima de
tudo, a qualidade do produto.
Uma dessas propostas é a tecnologia de Orientação a Objetos, comumente conhecida como
OO. Um dos principais objetivos dessa tecnologia é auxiliar no desenvolvimento de softwares em
partes que cumpram funções claras, que sejam facilmente compreendidas e integradas. Tais par-
tes são, também, conhecidas como "componentes". Para um desenvolvedor de software, a grande
vantagem em se trabalhar com uma tecnologia de componentização é poder identificar, isolar,
projetar, programar e testar, individualmente, cada componente, para, depois integrá-los gradual-
mente, de forma que seja possível obter um sistema completo.
O fundamento da tecnologia de Orientação a Objetos, como o próprio nome diz, é o obje-
to. Para entender esse conceito, inicialmente consultaremos um dicionário.
No dicionário Houaiss (2008), objeto é uma "coisa material que pode ser percebida pelos
sentidos; coisa mental ou física para a qual converge o pensamento, um sentimento ou uma
ação; assunto sobre o qual versa uma pesquisa ou ciência; móvel de um ato; agente, motivo,
causa".
Portanto, de acordo com essa definição, um objeto é uma coisa do mundo real que possui
características que podem ser identificadas, tais como: nome, tipo etc.
Se observarmos o mundo onde vivemos, vamos nos deparar com uma realidade na qual
incontáveis objetos estão por toda parte. Como exemplos de objetos comuns a nós, podemos
citar uma cadeira, um automóvel, uma pessoa etc.
Podemos concluir, de acordo com a definição de Houaiss, que nem todo objeto é "pal-
pável" e, portanto, não precisa, necessariamente, ser material. Podemos citar como exemplos
dessa categoria de objetos um serviço de manutenção, uma aula etc.
O que os objetos têm a ver com os sistemas informatizados? É simples, pois construímos
sistemas que armazenam dados sobre coisas e depois buscamos processar esses dados em in-
formações, não é mesmo? Pois bem. Muitas vezes, essas coisas são: alunos, funcionários, disci-
plinas, serviços de manutenção etc.
A tecnologia de Orientação a Objetos não é tão nova assim. Ela foi proposta no final da
década de 1970 com a linguagem de programação SmallTalk, e só na década de 1990 é que co-
meçou a ser utilizada com maior frequência.
© U1 – Visão Geral da Análise e Projeto de Sistemas 43

A Orientação a Objetos é considerada um paradigma de desenvolvimento de software.


Atualmente, todas as linguagens de programação modernas, tais como: Delphi, Java, PHP, C#
etc., suportam essa tecnologia.
Historicamente, a linguagem de programação Orientada a Objetos surgiu primeiro. Cha-
mamos, então, essa tecnologia de Programação Orientada a Objetos. Posteriormente, para me-
lhor orientar o desenvolvimento de software com a programação orientada a objetos, surgiram
várias propostas de técnicas de análise e modelagem específicas. Chamamos essas outras tec-
nologias de Análise e Projeto Orientados a Objetos.
A Análise, Projeto e Programação Orientados a Objeto representam tecnologias moder-
nas, amplamente utilizadas por empresas no desenvolvimento de novos projetos de software
que têm como objetivo atingir padrões de qualidade.

Modelos
Quando se trata de desenvolvimento de sistemas de software, os modelos são criados por
meio de notações gráficas e textuais. A Linguagem de Modelagem Unificada, conhecida pela
sigla UML (Unified Modeling Language), é uma linguagem visual para modelar sistemas orien-
tados a objetos.

Visões de um sistema
Um sistema tende a ser mais complexo à medida que seu tamanho aumenta e as pessoas
envolvidas no seu desenvolvimento o "enxergam" sob diferentes perspectivas, de acordo com o
que lhes interessa.
Desse modo, a maior parte dos sistemas desenvolvidos sob o paradigma da orientação a
objetos utiliza três modelos para sua descrição completa. Esses modelos são:
• modelo de classes;
• modelo de estados;
• modelo de interações.
Cada um deles representa aspectos diferentes do sistema. O modelo de classes está rela-
cionado com os aspectos estáticos do sistema; o modelo de estados relaciona-se aos aspectos
comportamentais e, finalmente, o modelo de interações está relacionado com os aspectos de
colaboração entre os objetos do sistema.
Embora cada modelo descreva aspectos diferentes do sistema, eles estão relacionados
entre si. No próximo tópico, veremos as particularidades de cada modelo e sua importância na
descrição do sistema.
A seguir, você verá a descrição dos três modelos.

Modelo de classes
Para (Blaha e Rumabugh, 2006), o modelo de classes é considerado o modelo mais impor-
tante dos três, pois descreve objetos. Assim, o modelo de classes relaciona-se com os demais,
pois descreve a estrutura de dados em que os modelos de estado e interações operam. Na UML
este modelo é representado pelo diagrama de classes.
No desenvolvimento de sistemas, o modelo de classes é construído com o objetivo de desco-
brir os conceitos do mundo real que são importantes para o sistema. Ele captura a estrutura estática
de um sistema, mostrando os relacionamentos entre os objetos, seus atributos e suas operações.

Claretiano - Centro Universitário


44 © Análise e Projeto de Sistemas

Modelo de estados
Relacionado aos aspectos temporais de um sistema, segundo Blaha e Rumbaugh (2006,
p. 167), "o modelo de estados descreve os aspectos de um objeto relacionados ao tempo –
eventos que marcam mudanças e estados que definem o contexto para os eventos.". Na UML é
representado pelo diagrama de estados, em que são mostradas as sequências de estados ocor-
ridas em cada classe definida para o sistema. A mudança de um estado para outro ocorre por
meio de um evento que acontece no ambiente do sistema.

Modelo de interações
O modelo de interações, como o próprio nome sugere, descreve as interações entre os
objetos, isto é, a colaboração entre eles. Representado pelos Casos de Uso (descrição das inte-
rações que ocorrem entre os atores do sistema e o sistema), diagramas de sequência (interação
entre os objetos, por meio da troca de mensagens) e diagramas de atividades.
Mas qual das duas técnicas devo utilizar?
Uma das principais justificativas para a escolha do paradigma Orientado a Objetos é que,
ao longo do tempo, os desenvolvedores perceberam que os processos, alvos principais das téc-
nicas clássicas de análise estruturada, como a Análise Essencial, possuem menor persistência ou
constância ao longo do tempo. Os conjuntos de objetos e os seus atributos (classes e objetos de
um sistema) são mais constantes e sofrem menos modificações que as operações que eles reali-
zam ou que são realizadas sobre eles. Dito de outra forma, os processos modificam-se muito ao
longo do tempo e os conjuntos de dados tendem a ser mais constantes.
Os desenvolvedores de tecnologia, então, construíram mecanismos para proteger melhor
os conjuntos de dados: as linguagens de programação Orientadas a Objetos. Essas linguagens
são utilizadas para construir sistemas mais fáceis de serem mantidos ou modificados ao longo
do tempo. Essa é uma vantagem importante, pois diminui o esforço e, consequentemente, o
custo de manutenção.
Entretanto, apesar das vantagens da abordagem orientada a objetos sobre a abordagem
voltada aos processos serem mais evidentes, o Analista de Sistemas precisa conhecer bem essas
duas abordagens. É possível que, por razões estratégicas, a abordagem voltada à análise por
processos deva ser utilizada. Constatamos, também, que talvez a maior parte dos sistemas em
uso esteja implementada nessa abordagem e, assim, precisamos compreender a documentação
para realizar a manutenção desses sistemas com a qualidade necessária.
Outra possibilidade é de que, talvez, tenhamos de documentar sistemas não implemen-
tados em linguagens orientadas a objeto e, assim, a análise pela abordagem de processos será
mais adequada. Mas tudo isso vai depender do conhecimento que o analista possui sobre as
técnicas e ferramentas de cada uma das diferentes abordagens.

8. O PERFIL DO PROFISSIONAL QUE REALIZA ANÁLISE E PROJETO DO SOFTWARE


Delimitar as habilidades e competências das atribuições do profissional que realiza análise
e projeto de sistemas não é uma tarefa trivial.
Você já percebeu, ao longo da leitura das atividades e tarefas do processo de desenvol-
vimento da NBR ISO/IEC 12207, que esse profissional deve ter diversas competências e habili-
dades tecnológicas. Mas, também, precisamos considerar que ele trabalha em parceria com a
organização administrativa de um projeto, muitas vezes sendo ele mesmo o gerente. Ele traba-
© U1 – Visão Geral da Análise e Projeto de Sistemas 45

lha, também, com um analista de negócios, alguém que deve ter uma boa visão de tecnologia e,
certamente, um conhecimento profundo de sistemas administrativos.
Percebe-se que o analista de sistemas é um elemento importante em um projeto, pois ele
irá se relacionar com todos os envolvidos, inclusive com os futuros usuários e com o cliente que
solicitou o software. Portanto, as habilidades de relacionamento interpessoal também lhe são
requeridas.
A literatura especializada aponta um conjunto de habilidades que vale a pena parar para
refletir. De acordo com Pompilho (2002), são elas:
a) Comunicação: é preciso que este profissional saiba ouvir, redigir e expor ideias com
clareza e precisão.
b) Capacidade de análise: é ideal que este profissional desenvolva uma visão sistêmica e
crítica do contexto do problema que está sendo estudado.
c) Conhecimento da área na qual o problema está sendo estudado: preferencialmente
adquirido por meio da experiência pessoal.
d) Capacidade de negociação: é preciso que este profissional saiba administrar conflitos
de interesses interpessoais que surjam durante o trabalho em grupo.
e) Administração de projetos: é ideal que este profissional tenha noções de planejamen-
to e acompanhamento de projetos.
f) Conhecimento técnico: é necessário conhecer e saber utilizar bem as ferramentas de
modelagem para especificar os sistemas.
A seguir, vamos fazer algumas considerações importantes.
É comum encontrarmos bons programadores que trabalham muito bem e produzem
softwares que atendem às necessidades pelas quais foi solicitado. É comum, também, muitos
profissionais acharem que vários procedimentos, como os apresentados anteriormente, na
NBR ISO/IEC 12207, apenas adicionam uma carga enorme de "burocracia", sendo até causa
de atraso ou insucesso de projetos.
Para esses casos, propomos uma breve analogia com o processo de construção civil. Essa
analogia deve ser considerada como uma simples comparação do processo produtivo, visto que
a filosofia administrativa é a mesma. Na realidade, o software é uma categoria de produto com
especificidades que o tornam muito diferente em alguns aspectos.
Muitos construtores fizeram "escola da vida", aprendendo com outros profissionais mais
experientes. A competência desses profissionais não pode ser questionada, considerando que
vários deles são capazes de realizar construções excelentes.
A demanda por construções cada vez maiores e mais complexas ao longo do desenvolvi-
mento da civilização humana fez com que o ser humano buscasse tecnologias que o pudessem
ajudar nos empreendimentos cada vez mais sofisticados.
Embora a base de construção seja praticamente a mesma, isto é, assentar tijolos, argamassa
etc., construções mais ousadas, tais como: um grande edifício, uma ponte ou um shopping center,
apresentam restrições severas de complexidade, tempo de construção, custo etc. que, muitas ve-
zes, são vistas como os principais fatores de qualidade pelo cliente que solicitou a obra. Portanto,
é necessário muito estudo e planejamento, além do envolvimento de muitos profissionais com
habilidades específicas: arquiteto, engenheiro civil, mestre de obras, carpinteiro, pedreiro etc.
Ao transpormos essas ideias para o mundo do software, percebemos claramente que a
demanda por soluções tem exigido das empresas a mesma performance.

Claretiano - Centro Universitário


46 © Análise e Projeto de Sistemas

O programador individual é um profissional artesão, capaz de desenvolver pequenos pro-


jetos com sucesso. No entanto, as suas habilidades estão restritas ao porte e à complexidade
dos sistemas que ele produz.
Atualmente, temos muitas instituições de ensino superior, tecnológico e técnico, espe-
cializadas em formar o profissional da área de informática, mas nas décadas passadas (anos
de 1960, 1970) era muito mais difícil a formação acadêmica de um profissional da área. Muitas
pessoas aprendiam na prática, tornando-se analistas de sistemas e/ou programadores pela ex-
periência acumulada no desenvolvimento de suas funções.

9. QUESTÕES AUTOAVALIATIVAS
Sugerimos que você procure responder, discutir e comentar as questões a seguir que tra-
tam da temática desenvolvida nesta unidade.
A autoavaliação pode ser uma ferramenta importante para você testar o seu desempenho.
Se você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos
estudados para sanar as suas dúvidas. Esse é o momento ideal para que você faça uma revisão
desta unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocor-
re de forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus
colegas.
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:
1) O software é uma categoria de produto. No entanto, sua produção não pode ser comparada a um produto
manufaturado, produzido em série nas indústrias. Reflita sobre essas diferenças de produção e estabeleça uma
comparação entre os produtos manufaturados e produtos de software.

2) Considerando-se o ciclo de vida de um software, identifique as etapas em que ocorre a produção de modelos
do software a serem desenvolvidos. Analise as atividades em cada uma das etapas.

3) Reflita sobre a importância da modelagem de sistemas no desenvolvimento de software. Em que implica a omis-
são dessa etapa? Analise as consequências dessa omissão para o processo de desenvolvimento de software.

Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
1) Embora seja classificado como um produto, o software é um produto de natureza intelectual. Isso diferencia
sua produção de outros produtos produzidos em série. Para esses últimos, desde que os equipamentos utiliza-
dos na produção estejam devidamente regulados, todo produto gerado deverá ter as mesmas características,
além de maior rapidez na produção (processo repetitivo). Quando se trata da produção de software, estamos
trabalhando com pessoas que entram em um processo de criação. Isso significa que os produtos, por mais se-
melhantes que sejam suas funcionalidades, dificilmente serão idênticos. Além disso, o tempo para a criação de
um software é, provavelmente, muito maior do que o tempo gasto para a fabricação de um produto em série.
Portanto, o software não é um produto manufaturado, mas fruto de um processo criativo e, assim, considerado
uma produção intelectual.

2) O ciclo de vida de um software é composto por algumas etapas caracterizadas pelas tarefas que nelas ocorrem.
Você pode encontrar, diferenças na nomenclatura dessas etapas, considerando cada referência pesquisada.
Porém, o que ocorre em cada uma delas não muda por causa disso. Por exemplo, o ciclo de vida de um sistema
pode ser definido pelas etapas: – concepção (quando nasce a ideia do desenvolvimento de um sistema, nor-
malmente por parte do cliente); – levantamento de requisitos (trabalho realizado junto ao cliente/usuário, em
que procura conhecer sobre o sistema, ou seja, definir quais são as necessidades dos usuários e o que o sistema
deverá oferecer); análise (os requisitos levantados na etapa anterior são analisados e, então, o objetivo é de-
terminar a solução para o problema – "o que fazer"; essa fase não considera as restrições tecnológicas para o
sistema); – projeto (as restrições tecnológicas são levadas em consideração; nessa fase, a solução para o proble-
ma já existe, e a preocupação é definir "como" ela será executada); – implementação (etapa em que é realizada
toda a programação do software, ou seja, as estratégias definidas nas duas etapas anteriores, representadas em
© U1 – Visão Geral da Análise e Projeto de Sistemas 47

documentos ou artefatos, são agora traduzidas para uma linguagem de programação); – testes (etapa em que
são realizadas atividades que garantam que o software realize as funções para as quais foi projetado, atendendo
às expectativas do cliente, sem conter erros); – implantação (etapa em que o software é colocado no ambiente
do cliente); – manutenção/evolução (etapa que pode ocorrer depois que o software está em funcionamento
no ambiente do cliente, por motivos de mudanças nos requisitos do sistema, ou no ambiente em que o sistema
está inserido). Assim, respondendo à questão, os modelos são construídos nas etapas de análise e projeto, e
são construídos com o objetivo de representar o software e mostrar as diferentes perspectivas dele, permitindo
que o cliente e seus futuros usuários tenham uma visão do que será o produto, mesmo antes de ele ser cons-
truído.

3) A modelagem de software é importante, uma vez que os modelos representam o sistema que será construído.
Várias são as razões para isso, tais como: – permitir a comunicação entre desenvolvedores, clientes e usuários;
– reduzir custos, pois os problemas que poderiam existir após a implementação podem ser antecipados e corri-
gidos ainda na fase de projeto; – antever o comportamento do sistema; – diminuir a complexidade do software
pela representação do mesmo por diferentes modelos, ou seja, nas etapas de análise e projeto vários modelos
são desenvolvidos, cada qual representando uma perspectiva diferente do sistema, o que facilita a compre-
ensão do sistema. Portanto, quando um sistema não é devidamente modelado e documentado, o produto
construído poderá apresentar deficiências nos requisitos levantados e o sistema não funcionará como deveria
para atender às expectativas do usuário. Além da frustração do usuário em relação ao produto obtido, devemos
contabilizar o prejuízo de tempo e dinheiro, pois isso implica em retrabalho.

10. CONSIDERAÇÕES
Com o estudo desta unidade você teve a oportunidade de compreender o desenvolvi-
mento de um software baseado em uma perspectiva profissional. Você teve a oportunidade
de conhecer a NBR ISO/IEC 12207 – Processos de ciclo de vida do software – que relaciona as
atividades e tarefas envolvidas no processo de desenvolvimento do software.
Também teve a oportunidade de conhecer os principais estágios de projeto de sistemas
são: o projeto arquitetural, o projeto de interface, o projeto detalhado e o projeto de dados.
Além disso, apresentamos o "Ciclo de vida", que é o termo utilizado nos processos produtivos
para expressar a ideia de que um produto ou serviço tem a sua existência, desde a sua concep-
ção até o momento em que não é mais utilizado.
Também apresentamos os principais conceitos de análise e projeto de software que são:
abstração, refinamento, modularidade. A abordagem de análise voltada a processos é uma téc-
nica consolidada, porém, para sistemas modernos, há uma tendência maior de utilização de tec-
nologias de implementação orientadas a objetos e, para isso, a abordagem orientada a objetos
também é mais adequada. O papel do profissional que realiza análise e projeto de sistemas é
desenvolver estudos e desenhar a solução mais adequada ao domínio do problema.
Esperamos que você aprofunde seus conhecimentos com as leituras indicadas sobre estes
assuntos. Conhecer as fontes do conhecimento da análise de sistemas pode ajudá-lo futuramen-
te no desempenho de suas atividades.

11. E-REFERÊNCIAS

Sites pesquisados
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Série ISO 9000:2000: sistemas de gestão da qualidade. Disponível em: <http://
www.abnt.org.br>. Acesso em: 01 jan. 2010.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 12207. Disponível em: <http://www.iso.ch>. Acesso em: 01
jan. 2010.

Claretiano - Centro Universitário


48 © Análise e Projeto de Sistemas

12. REFERÊNCIAS BIBLIOGRÁFICAS


BLAHA, M; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. Rio de Janeiro: Elsevier, 2006.
BOOCH, G. et al. UML: guia do usuário. Rio de Janeiro: Campus, 2000.
DeMARCO, T. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989.
GANE, C.; SARSON, T. Análise estruturada de sistemas. São Paulo: LTC, 1983.
HOUAISS, A. Dicionário eletrônico Houaiss da língua portuguesa. s.l.: Objetiva, 2008.
McMENAMIM, S. M.; PALMER, J. F. Análise essencial de sistemas. São Paulo: McGraw-Hill, 1991.
POMPILHO, S. Análise essencial: guia prático de análise de sistemas. Rio de Janeiro: Ciência Moderna, 2002.
PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.
YOURDON, E. Análise estruturada moderna. Rio de Janeiro: Campus, 1990.
EAD
O Modelo Essencial

1. OBJETIVO
• Conhecer a Análise Essencial de Sistemas, as suas abordagens e ferramentas de mode-
lagem.

2. CONTEÚDOS
• Modelo Ambiental: Declaração dos objetivos gerais, Diagrama de Contexto e Lista de
Eventos.
• Modelo Comportamental: Diagrama de Entidade-Relacionamento (DER), Diagrama de
Estrutura de Dados, Normalização de Dados, Dicionário de Dados, Diagrama de Fluxo
de Dados (DFD), Miniespecificações e Diagrama de Transição de Estados.

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) No início e durante o desenvolvimento das unidades, é importante que você sempre
fique atento às informações contidas no material didático. Programe, organize seus
estudos e participe ativamente na Sala de Aula Virtual. Ter disciplina para estudar
pode ajudar você a tirar o máximo de proveito de seu curso na modalidade Educação
a Distância.
2) Neste estudo, você verá que os modelos produzidos com a técnica de Análise Essen-
cial podem e devem ser explorados na fase de modelagem da engenharia de requisi-
50 © Análise e Projeto de Sistemas

tos, para ajudar na compreensão do sistema, especialmente quando se tratarem de


sistemas maiores e complexos ou, então, quando o analista ainda não possui muita
experiência no domínio de informação. Dessa forma, os requisitos serão compreendi-
dos e, consequentemente, melhor especificados.
3) Na Engenharia de Software o conceito de "caixa-preta" significa que, para que um
determinado processo ocorra, é fundamental conhecermos as entradas que o alimen-
tam e as saídas produzidas por ele. Entretanto, não sabemos como o processo é rea-
lizado.
4) Muitas vezes podemos pensar, inicialmente, que o objetivo de um sistema seja con-
trolar algo em uma organização, tal como: controle de vendas, de estoque, de equipes
etc. Todavia, na maioria dos casos, quem realiza o controle é sempre uma pessoa: al-
gum encarregado, gerente ou diretor, que executa efetivamente o controle. O sistema
é, na realidade, um repositório de dados que, ao serem processados, geram saídas
na forma de consultas e relatórios, disponibilizando informações para que o controle
ocorra com minimização de erros e riscos, tornando o trabalho mais eficiente e efi-
caz.
5) É importante lembrar que uma das fases da engenharia de requisitos é a modelagem
e, portanto, as ferramentas da Análise Essencial que geram modelos são utilizadas
nesse momento.
6) A modelagem de dados é apresentada, geralmente, na disciplina Banco de Dados. Não
pretendemos replicar tais conhecimentos, mas você vai descobrir a forte integração
dos conceitos.
7) Na disciplina de Banco de Dados, são apresentados os conceitos sobre normalização.
Entretanto, é recomendável que você dedique algum tempo livre para o aprofunda-
mento dos conhecimentos, pesquisando mais sobre este assunto e outros de seu in-
teresse.
8) Os DFDs são ferramentas importantes para a modelagem de sistemas e podem ser
utilizados em atividades de estudo e aperfeiçoamento de processos administrativos.
De acordo com Yourdon (1990), o primeiro uso de DFDs foi na área de Engenharia de
Software, em estudos de problemas de projeto de sistemas. As notações de represen-
tação foram trazidas de trabalhos sobre a teoria dos grafos.
9) De acordo com Stair (1998), uma transação é qualquer troca ou movimentação de
dados e informações relacionadas a negócios. Um Sistema de Processamento de Tran-
sações (SPT) é um sistema especializado composto tipicamente por pessoas, procedi-
mentos, bancos de dados e dispositivos usados para registrar transações de negócios
completas. As principais aplicações de processamento de transações são: proces-
samento de pedidos, fatura, controle de estoque, contas a receber, contas a pagar,
compras, recebimentos, expedição, folha de pagamento e contabilidade em geral. Há,
também, sistemas especializados de processamento de transações, como é o caso de
serviços de saúde, serviços bancários, gerenciamento de energia, serviços públicos
etc. Embora o trabalho de um Analista de Sistemas não envolva somente o desenvol-
vimento de sistemas de informação, a maioria dos softwares utilizados ainda é dessa
categoria. O estudo das características desses sistemas pode ajudar você a desenvol-
ver as suas atividades de análise, quando se tratarem de Sistemas de Processamento
de Transações.
10) Atividades essenciais são todas as tarefas que o sistema tem de executar para atingir
seu propósito. As atividades essenciais não se comunicam diretamente, mas apenas
via base de dados. Em outras palavras, são assíncronas, independentes entre si. Isso
é coerente com a visão de um sistema, como uma máquina de resposta planejada. A
secretária pode cadastrar alunos, enquanto outros alunos podem solicitar emissão de
boletim e, ao mesmo tempo, o gerente pode solicitar a emissão de um relatório men-
sal de fechamento de caixa etc. Podemos perceber que esses eventos estão ocorrendo
de forma assíncrona, sem uma sequência definida.
© U2 – O Modelo Essencial 51

11) Um dos tópicos avançados dentro do estudo da Engenharia de Software são os Méto-
dos Formais. Dentro dessa área estudam-se propostas de linguagens de especificação
formal. Consulte o capítulo 25 do livro Engenharia de Software, de Pressman, cuja
referência completa está disponível no final deste material, no tópico de Referências
Bibliográficas, para saber mais sobre este assunto.

4. INTRODUÇÃO À UNIDADE
Na unidade anterior, você teve a oportunidade de compreender a integração entre as ati-
vidades utilizadas no processo produtivo do software e, também, de perceber que o papel do
Analista de Sistemas é importante para o desenvolvimento de um software com qualidade.
Nesta unidade, você terá a possibilidade de aprender a utilizar, corretamente, técnicas de
modelagem e projetos de sistemas sob a abordagem da Análise Essencial de Sistemas.

Problematizando o tema
Analisar e projetar um sistema não são tarefas simples e demandam muita atenção e cui-
dado. Por onde devemos começar? Quais tarefas devem ser utilizadas? Elas se complementam?
Como? Quais modelos, documentos etc., devem ser produzidos?
Apenas relembrando, estudaremos duas abordagens de desenvolvimento de sistemas: a
abordagem da Análise e Projetos Estruturados (também conhecida como Análise Essencial) e a
abordagem da Análise e Projeto Orientados a Objetos.
Nesta unidade veremos, então, a primeira abordagem, ou seja, a Análise e Projetos Estru-
turados. Você conhecerá as ferramentas que o analista pode ter em mãos para o desenvolvi-
mento de sistemas, por meio de tecnologia estruturada, numa perspectiva voltada, inicialmen-
te, ao estudo dos processos que um sistema executa, ou seja, as suas funções.

5. ENFOQUES DA ANÁLISE ESSENCIAL DE SISTEMAS


A Análise Essencial de Sistemas é adequada à investigação sistemática do domínio de um
problema a ser solucionado, com um sistema baseado em computador nas fases de análise,
especificação e projeto.
A Análise Essencial de Sistemas é utilizada para investigar sistemas já desenvolvidos, por
exemplo, para documentação – ou redocumentação, caso ela tenha se perdido – de software ou
de novos projetos que utilizarão o paradigma da programação estruturada, ou seja, sem o uso
da tecnologia de Orientação a Objetos. Para o paradigma de Orientação a Objetos, a UML – Lin-
guagem de Modelagem Unificada – é mais adequada.
Cada ferramenta utilizada nesta abordagem deverá produzir um tipo de modelo. Essa
abordagem tem como estratégia proceder ao exame de domínio do problema, ou seja, realizar
o levantamento de dados acerca do sistema que será desenvolvido, inicialmente enfocando os
aspectos mais essenciais ou fundamentais do problema. Daí a denominação Análise Essencial.
Vale ressaltar que, como qualquer outra abordagem de análise, a premissa básica é des-
crever o sistema de maneira independente de quaisquer restrições tecnológicas (linguagens de
programação, sistemas operacionais etc.).
A abordagem essencial organiza o estudo do problema com base em dois enfoques princi-
pais, que irão compor duas visões distintas:
Claretiano - Centro Universitário
52 © Análise e Projeto de Sistemas

• Visão externa: são os elementos do ambiente em que o problema e, consequentemen-


te, a solução estão inseridos, os quais provocarão estímulos ao sistema.
• Visão interna: detalhamento de como devem ser as reações aos estímulos externos.
Estes dois enfoques são denominados de modelagem ambiental, para a visão externa, e
modelagem comportamental, para a visão interna.
Três atividades são desenvolvidas no modelo ambiental:
• Elaborar a Declaração dos Objetivos do Sistema;
• Elaborar o Diagrama de Contexto;
• Construir a Lista de Eventos.
Sete atividades são desenvolvidas no modelo comportamental:
1) Elaborar o Diagrama do Modelo Entidade-Relacionamento;
2) Elaborar o Diagrama de Estrutura de Dados;
3) Normalizar as estruturas de dados;
4) Elaborar o Dicionário de Dados;
5) Elaborar o Diagrama de Fluxo de Dados;
6) Elaborar as Miniespecificações
7) Elaborar o Diagrama de Transição de Estados.
Vamos prosseguir nossos estudos detalhando, inicialmente, cada uma das atividades do
modelo ambiental.

6. MODELAGEM AMBIENTAL
Relembrando os conceitos que vimos anteriormente, no modelo ambiental tem-se a ma-
croespecificação do sistema. O sistema é visto como se fosse uma "caixa-preta", inserido em um
ambiente dinâmico, no qual estímulos de diversos tipos produzem algum tipo de resposta do
sistema. As respostas poderão ser internas ao sistema ou, ainda, serem devolvidas para o meio
ambiente.
Veja, a seguir, o detalhamento dessas atividades, que devem ser desenvolvidas neste mo-
delo.

Declaração dos objetivos do sistema


Compreender e definir exatamente quais são os objetivos do sistema é fundamental para
o projeto. A compreensão dos objetivos gerais do sistema delimita o problema ou escopo do
projeto. Essa definição deve deixar claro, em linhas gerais, o que o projeto atenderá para os
futuros usuários.
Busca-se, com essa declaração, especificar o que o sistema deverá responder frente aos
problemas existentes na organização que demanda um projeto de software. Deve, também,
tanto quanto possível, refletir os desejos principais dos usuários, no que diz respeito às solicita-
ções que eles tenham apresentado como alternativas de solução dos problemas.
As entrevistas e o levantamento inicial do problema dão pistas dessa delimitação. Usu-
almente faz-se um contato com o cliente (ou proponente do projeto) e os potenciais usuários
do sistema, ou seja, aqueles que conhecem o processo que será modelado e informatizado.
Podem, ainda, é possível utilizar entrevistas informais ou estruturadas previamente planejadas.
Se possível, deve-se coletar modelos de documentos para ajudar nesta tarefa.
© U2 – O Modelo Essencial 53

A função do detalhamento do estudo é esclarecer as dúvidas e confirmar essa declara-


ção.
Ao elaborar a Declaração dos Objetivos do Sistema, o analista deve redigir um texto breve
e conciso. O público-alvo dessa declaração é:
a) A gerência;
b) A equipe de desenvolvimento do projeto;
c) Os representantes da empresa que solicitaram o sistema;
d) Os futuros usuários.
Um exemplo de declaração é para um Sistema de Gestão Acadêmica (SGA). O objetivo
deste sistema é apoiar o controle acadêmico da Escola de Línguas Fale Fácil, atuando nos pro-
cessos de matrícula, acompanhamento de alunos e controle de caixa, disponibilizando informa-
ções estratégicas para que a Diretoria administre a instituição.
Recomenda-se que essa declaração tenha algumas sentenças, mas que não ultrapasse um
parágrafo, de forma que os objetivos sejam compreendidos com informações concisas.
A declaração não precisa ser detalhada e abrangente, visto que o restante do modelo
ambiental e do modelo comportamental deverá fornecer esses detalhes. Procure enfatizar os
objetivos finais do sistema frente ao negócio, empreendimento ou necessidade do usuário. Pro-
cure, também, não detalhar as funções, mas abstrair as razões principais do desenvolvimento
do sistema.

Diagrama de Contexto
A segunda ferramenta da modelagem ambiental é um diagrama: o Diagrama de Contex-
to. Este diagrama modela o sistema por um único processo, representado por um círculo que
explicitando as interligações com os elementos do ambiente, chamados de entidades externas,
representado por um retângulo. A interação é realizada por meio de fluxos de entrada e de saí-
da, representados por setas. Observe a Figura 1.

Fluxo de entrada
Entidade
Externa
Nome
do
Sistema

Fluxo de saída

Figura 1 Elementos gráficos do Diagrama de Contexto.

O Diagrama de Contexto apresenta uma visão de alto nível do sistema analisado, mostran-
do-o como uma "caixa-preta", ou seja, ainda não sabemos o que ocorre internamente para que
ele possa responder aos estímulos provocados no ambiente. Todavia, ficam explicitamente de-
limitados os limites de atuação do sistema. O Diagrama de Contexto utiliza os símbolos gráficos
de um Diagrama de Fluxo de Dados, que você estudará mais adiante, nesta unidade. Observe
que o processo é simbolizado por um círculo, os retângulos representam as entidades externas
e as setas, os fluxos de entrada e saída de dados do sistema.

Claretiano - Centro Universitário


54 © Análise e Projeto de Sistemas

Ao elaborar um Diagrama de Contexto, é importante conferir se os fluxos de saída são


respostas que devem ser produzidas por algum estímulo do ambiente. Em princípio, não deve
existir nenhum fluxo de entrada, no sistema, que não tenha origem em um estímulo de alguma
entidade externa. Uma entidade externa não é uma pessoa física, mas um papel desempenhado
por ela. Por exemplo, não identificamos uma entidade pessoa chamada Maria, nem João, mas o
papel de Maria como Secretária, e o papel de João como gerente.
Uma entidade externa é uma fonte ou destino de um fluxo, algo situado fora do sistema.
Pode ser uma classe de usuários ou até mesmo algum outro sistema externo que troque dados
com o sistema a ser desenvolvido. Exemplos: gerente, secretária, operador, sistema de controle
de estoque etc. Cuidado! Uma entidade externa não é uma tabela.
Desse modo, é necessário que os fluxos de dados sejam nomeados, expressando resumi-
damente o significado do conjunto de informações que está fluindo.
O Diagrama de Contexto para um sistema de controle acadêmico está apresentado na
Figura 2.

Secretária
Solicita Solicita
cadastro de Registro
Alunos de Notas
Secretária Solicita Mensagem Secretária
Registro de
de Faltas confirmação
ou rejeição
Mensagem de Mensagem Solicita cadastro de
confirmação ou de Cursos
rejeição confirmação
ou rejeição Secretária
Solicita registro de
Matrícula Mensagem de confirmação ou
Secretária rejeição

Mensagem de
confirmação ou Solicita emissão Secretária
rejeição
Sistema de boletim
Escola de
Línguas
Solicita Boletim
cadastro de
Professores
Secretária Aluno
Recibo
Mensagem de
confirmação ou
rejeição
Solicita
relatório de
fechamento
Solicita cadastro
de caixa
de Turmas Lista de Solicita
presença registro de Mensagem
Secretária pagamento
Diretor
Planilha de Relatório de
de confirmação
de notas fechamento
mensalidade ou rejeição de caixa

Secretária

Figura 2 Diagrama de Contexto para o sistema de gestão acadêmica.

Lista de eventos
A lista de eventos é elaborada com base no levantamento de requisitos, realizado no iní-
cio do ciclo de vida de um sistema, conforme já foi estudado na Unidade 1. Para isso, existem
diversas técnicas, tais como entrevistas com os usuários do sistema, observações sobre a forma
de execução dos processos nos locais em que o sistema será implantado futuramente, análise
de documentos e reuniões com os usuários (brainstorm), para cada um expor suas ideias sobre
o sistema.
© U2 – O Modelo Essencial 55

Todo o levantado realizado por meio desses métodos é analisado, de forma que um docu-
mento sobre os requisitos do sistema possa ser elaborado. As entrevistas devem ser transcritas
na forma de frases, contendo verbos que traduzam aquilo que o sistema deve fazer para atender
às necessidades dos usuários.
Em linhas gerais, o sucesso de um sistema está na forma com que ele consegue atender às
necessidades de processamento de dados que seus usuários solicitam. Dessa forma, o sistema
deve ser construído para responder a essas solicitações, que chamaremos de "estímulos".
Os estímulos são os elementos ativadores das funções dos sistemas, e são provocados por
diversos tipos de acontecimentos ou eventos do mundo exterior, que requerem do sistema uma
resposta predeterminada. Ao produzir uma resposta a um dado evento, o sistema retorna ao
estado de inatividade até ser estimulado novamente por outro evento da mesma ou de outra
natureza.
Em nosso exemplo da "Escola de Línguas Fale Fácil", quando uma secretária matricula um
aluno, temos um evento. A matrícula do aluno é o estímulo, e a resposta do sistema é responder
se o aluno foi ou não matriculado.
Uma resposta é sempre o resultado da execução de alguma função interna ao sistema,
como consequência do reconhecimento pelo sistema de que um evento ocorreu. Usualmente
essa resposta pode ser:
• Um fluxo de dados saindo do sistema para uma Entidade Externa, como, por exemplo,
uma mensagem textual de confirmação, o resultado de uma consulta ou uma listagem
de dados;
• Uma mudança de estado do sistema, geralmente de uma estrutura ou um depósito
de dados, um arquivo ou uma tabela, como, por exemplo, uma inclusão, exclusão ou
alteração de dados;
• Um fluxo de controle saindo de uma função para ativar outra função.
Um evento é identificado como uma atividade essencial, pois provoca a produção de res-
postas (princípio da ação e reação). Em outras palavras, devemos associar a cada evento um
estímulo, ou seja, uma mensagem que fluirá para dentro do sistema. Uma atividade essencial
tratará desta mensagem, produzindo respostas internas e/ou externas.
Para você compreender melhor a natureza dos eventos e os tipos de respostas que os seus
estímulos esperam, vamos estudar a seguinte classificação:
• Eventos orientados a fluxo de dados;
• Eventos temporais;
• Eventos orientados a fluxo de controle.
Os eventos orientados a fluxo de dados são aqueles disparados por entidades externas
que enviam solicitações de manutenção de dados (inclusão, alteração ou exclusão), consultas
ou relatórios. Entretanto, um sistema pode ou não produzir resposta externa a um evento orien-
tado por fluxo de dados.
Geralmente, a maioria dos eventos orientados a fluxo de dados de um sistema é dessa
categoria.
Para identificar um evento orientado por fluxo de dados, você deverá observar, nas trans-
crições de entrevistas sobre os processos estudados, uma estrutura do tipo:
Sujeito + verbo transitivo na voz ativa + complemento verbal

Claretiano - Centro Universitário


56 © Análise e Projeto de Sistemas

Exemplos dessa categoria de eventos são:


• Secretária matricula aluno;
• Secretária altera dados de aluno;
• Gerente emite relatório de fechamento de caixa.
Os eventos temporais, como o próprio nome sugere, são disparados por uma informação
relativa a um ponto temporal específico ou a um determinado intervalo de tempo predefinido.
Para isso, o sistema fica monitorando um dispositivo ou relógio interno que marca a passa-
gem do tempo e dispara a funcionalidade em momento predeterminado, ou seja, não é por meio
da chegada de um fluxo de dados que o sistema toma conhecimento da ocorrência do evento.
Entretanto, pode haver fluxo de dados complementares associados ao evento temporal.
Exemplos dessa categoria de eventos são bem específicos, mas podem ser comuns. Imagine
um sistema de controle de reservas de um hotel. Os atendentes fazem o registro de reservas re-
alizadas pelo telefone. Todavia, o cliente pode deixar de cancelar a reserva e, enquanto isso, seu
quarto pode permanecer bloqueado pelo sistema. Então, deseja-se que o sistema realize o cance-
lamento automático de todas as reservas não registradas todos os dias, às 12 horas e 1 minuto.
Para identificar um evento temporal você deverá observar, nas transcrições de entrevistas
sobre os processos estudados, uma estrutura do tipo:
"É hora de" + verbo no infinitivo + complementos verbais
Exemplos dessa categoria de eventos são:
• É hora de cancelar o não comparecimento;
• É hora de gerar relatório de fechamento de despesas do hóspede.
Um evento orientado a fluxo de controle tem como característica a ativação por um fluxo
de controle na forma de uma variável binária. O fluxo de controle é um fluxo de dados binário,
isto é, só tem dois valores possíveis: ligado ou desligado.
O fluxo de controle pode ser enviado por uma entidade externa ou ser gerado por uma
função interna do sistema. São os casos, por exemplo, em que um fluxo de dados está interrom-
pido, não sendo processado automaticamente, na espera de uma mensagem de liberação ou
cancelamento, e essa mensagem não é uma informação relativa ao tempo.
É como se fosse um caso especial de evento temporal, no qual o estímulo externo ocorre
em um ponto imprevisível no tempo. Todavia, ele difere do evento temporal real, pois não está
associado com a passagem regular do tempo, de forma que o sistema o antecipe utilizando seu
relógio interno. Diferentemente, também, do evento orientado a fluxo, esse tipo de evento não
ativa nenhuma função por meio de um dado que chega.
Para identificar um evento orientado por controle, você deverá observar, nas transcrições
de entrevistas sobre os processos estudados, uma estrutura do tipo:
sujeito + verbo transitivo na voz ativa + complementos verbais
sujeito + verbo na voz passiva + complementos verbais
Exemplos dessa categoria de eventos podem ser comuns:
• A diretoria autoriza o pagamento de uma fatura;
• O nível mínimo do estoque é atingido.
O estudo ambiental de um sistema é importante para a especificação de requisitos, es-
pecialmente, nos casos de situações nas quais o analista ainda não tem muita experiência ou o
sistema possui especificidades que precisam ser examinadas em detalhes.
© U2 – O Modelo Essencial 57

As informações geradas durante a modelagem ambiental podem, ainda, levantar dúvidas


sobre alguns requisitos, e é saudável que isso aconteça. Nesses casos, é essencial que o analista
busque esclarecer tais dúvidas com o cliente e/ou usuário(s).
Para finalizar este assunto, lembre-se de que cada evento deve:
• Produzir uma saída imediata em sua resposta; ou
• Armazenar dados para saída posterior (como resposta ou parte de uma resposta de
algum outro evento); ou
• Causar uma mudança de estado no sistema (como indicado no diagrama de transição
de estado).
Uma forma adequada para se apresentar os eventos essenciais de um sistema é organizá-
-los em um quadro ou tabela. No Quadro 1, dispomos não apenas os eventos, mas também os
estímulos, ações e respostas correspondentes. Este quadro apresenta alguns eventos essenciais,
identificados para um sistema fictício de controle de pedidos.
Quadro 1 Lista de eventos essenciais para um sistema de gestão acadêmica.
NOME DO TIPO DE
Nº ESTÍMULO AÇÕES RESPOSTAS USUÁRIO
EVENTO FLUXO
A secretária Contratação de Professor
1 F Registrar professor Secretária
cadastra professor professor registrado
A secretária Abertura de nova
2 F Registrar turma Turma registrada Secretária
cadastra turma turma
A secretária Solicitação de
3 F Registrar aluno Aluno registrado Secretária
cadastra aluno matrícula
A secretária
Solicitação de Matrícula
4 matricula aluno F Registrar matrícula Secretária
matrícula efetuada
em turma
A secretária
Registrar Pagamento
recebe Pagamento de
5 F pagamento e emitir registrado e Secretária
mensalidade e mensalidade
recibo recibo emitido
emite recibo
A secretária Fechamento
registra as de diário do Registrar presenças Presenças e
6 F Secretária
presenças e faltas professor (planilha e faltas faltas registradas
dos alunos de presença)
A secretária
Fechamento de
7 registra as notas F Registrar notas Notas registradas Secretária
planilha de notas
das avaliações
A secretária emite
Solicitação de Emissão de
8 o boletim do F Emitir boletim Secretária
boletim boletim
aluno
O diretor emite Emissão de
relatórios de Solicitação de Emitir relatório de relatório de
9 F Diretor
fechamento de relatório fechamento de caixa fechamento de
caixa caixa
Legenda dos tipos de fluxo: F – Fluxo; T – Temporal; C – Controle

7. MODELAGEM COMPORTAMENTAL
Como você viu, a técnica de Análise Essencial propõe o estudo de um sistema do ponto de
vista externo e interno. O ponto de vista externo foi abordado anteriormente. O ponto de vista
interno é estudado com as ferramentas de modelagem comportamental.
Para este modelo, o sistema deverá ser compreendido como uma "caixa-branca". Do pon-
to de vista funcional, estrutural e comportamental, estudaremos o sistema até compreendê-lo

Claretiano - Centro Universitário


58 © Análise e Projeto de Sistemas

em detalhes que orientem a sua construção em uma linguagem de programação. Ao contrário


da caixa-preta, o conceito de "caixa-branca" nos remete à ideia de que não são conhecidas as
entradas e saídas para um processo, mas sim como o processo é realizado.
Dessa forma, o profissional que realiza análise e projeto de sistemas irá detalhar como
cada atividade existente na lista de eventos deve se comportar para produzir uma resposta. É
essencial, também, que o profissional produza um modelo de dados, observando e definindo
critérios que visem obter boa performance na sua utilização.
As atividades elaboradas neste modelo são:
1) Elaborar os documentos relativos ao ambiente de dados do sistema:
a) Elaborar o Diagrama do Modelo Entidade-Relacionamento;
b) Elaborar o Diagrama de Estrutura de Dados;
c) Normalizar os dados;
d) Elaborar o Dicionário de Dados.
2) Elaborar o Diagrama de Fluxo de Dados;
3) Elaborar as Miniespecificações;
4) Elaborar o Diagrama de Transição de Estados.
Para organizar o seu estudo, vamos agrupar as tarefas de a até d (Diagrama de Entidade-
Relacionamento, Diagrama de Estrutura de Dados, Normalização de Dados e Dicionário de Da-
dos) em uma atividade de Modelagem de Dados, pois todas elas estão envolvidas no estudo e
tratamento estrutural dos dados pelo sistema e serão estudadas a seguir.

Modelagem de dados
De acordo com Pompilho (2002), a modelagem de dados é um método de análise de sis-
temas utilizado para criar uma especificação sob a perspectiva dos dados. Esse método permite
que os dados sejam organizados em estruturas bem definidas, com regras bem estabelecidas de
dependência entre eles, expressas em um modelo ao mesmo tempo descritivo e diagramático.
A modelagem de dados é uma forma de análise. Na maioria das vezes, é papel do Analista
de Sistemas realizar esse estudo. Em equipes de grandes projetos, é comum existir um ou mais
profissionais específicos para o trabalho no domínio de dados, como é o caso do papel do admi-
nistrador de bases de dados.
Discutiremos os princípios da modelagem e projeto de bases de dados para que o conteú-
do da Análise Essencial não fique fragmentado, e ao mesmo tempo, contribuam com o enrique-
cimento de sua aprendizagem.

Modelagem Entidade-Relacionamento (MER)


Um banco de dados é uma coleção organizada de fatos e informações em forma de ar-
quivos logicamente relacionados. Usualmente, desenvolvemos sistemas que separam dados
da aplicação propriamente dita, dados esses de responsabilidade de outro software conhecido
como Gerenciador de Bases de Dados, que implementa uma tecnologia conhecida como Mo-
delo relacional. Portanto, a técnica de estudo da estrutura de dados a ser implementada reflete
essa tecnologia, que é chamada de Modelagem Entidade-Relacionamento também conhecida
como Modelagem conceitual.
© U2 – O Modelo Essencial 59

Essa técnica é um dos instrumentos de análise mais importantes, e apresenta, basicamen-


te, três construtores para a representação da semântica dos dados: entidades, atributos e rela-
cionamentos. Esses construtores têm os seus símbolos próprios. A informação é complemen-
tada com a indicação da cardinalidade dos relacionamentos. A Figura 3 apresenta o conjunto
desses símbolos e informações.

Cardinalidade Cardinalidade
Entidades A Entidades B

Conjunto Conjunto
de Entidades A de Entidades B

Relacionamento
Atributo chave Atributo chave
Atributo 1 Atributo 1
Atributo n Atributo n

Figura 3 Construtores do Modelo Entidade-Relacionamento (MER).

Vale ressaltar que o analista deve conhecer bem as possibilidades de representação dos
relacionamentos. Aproveite esta oportunidade e revise seus conceitos, realizando pesquisas so-
bre este assunto.
Para a modelagem de dados de uma aplicação, na visão da abordagem comportamental,
devemos tomar as funções de entrada, processamento e saída, que identificamos no documen-
to de requisitos desse sistema. Veja a lista:
a) Cadastro de professores.
b) Cadastro de turmas.
c) Cadastro de alunos.
d) Cadastro de matrículas.
e) Registro de recebimento de mensalidade e emissão de recibo.
f) Registro de presenças e faltas dos alunos.
g) Registro de notas de avaliações.
h) Emissão do boletim do aluno.
i) Emissão de relatórios de fechamento de caixa.
Quais dos eventos apresentados anteriormente devem gerar depósitos de dados? O estu-
do está relativamente simples. Todos os cadastros e registros enviam fluxos de dados que devem
ser armazenados e que são nossos candidatos a conjuntos de entidades. São eles: Professores,
Turmas, Alunos, Matrículas, Recebimentos, Presenças/Faltas e Notas.
Boletins e relatórios não são candidatos a conjuntos de entidades, visto que são operações
de extração de dados armazenados.
As presenças, faltas, notas 1 e 2 e prova supletiva podem ser vistas como dados relativos
à matrícula do aluno.
Se o diretor solicitar que o sistema realize controle de acesso, temos, portanto, outro con-
junto de entidades.
Para a determinação das cardinalidades, o analista supôs algumas situações e tirou as dú-
vidas em uma nova entrevista. A Modelagem Entidade-Relacionamento, ainda sem os atributos,
está apresentada na figura a seguir.

Claretiano - Centro Universitário


60 © Análise e Projeto de Sistemas

1 N N 1
Professor lecionar Turma formar Curso

M 1

matricular gerar

N
N
1 N
Aluno pagar Mensalidade

Figura 4 Modelo Entidade-Relacionamento preliminar para o sistema SGA.

O relacionamento "Aluno matricular Turma" está desdobrado na Figura 5.



1 N M N
Aluno fazer Matrícula possuir Turma

Figura 5 Desdobramento do relacionamento aluno e turma do sistema SGA.

Diagrama de estrutura de dados e passos para o modelo relacional


Depois de construir, revisar e validar o diagrama produzido na Modelagem Entidade-Re-
lacionamento, o passo seguinte é convertê-lo para aquilo que denominamos Modelo lógico
de dados, que é voltado para as características de implementação do Sistema Gerenciador de
Banco de Dados (SGDB). O Modelo lógico de dados faz parte do modelo de implementação do
sistema, ou seja, o modelo conceitual é um instrumento de análise e o modelo lógico é um ins-
trumento de projeto.
O Diagrama de Estrutura de Dados é um esquema que representa o projeto de um banco
de dados especificando a sua estrutura lógica. Esse modelo determina a composição e organiza-
ção dos depósitos que vão compor o banco de dados do sistema. Os diagramas de estrutura de
dados variam de acordo com a arquitetura de banco de dados selecionada.
Ao utilizarmos um banco de dados relacional, no qual o armazenamento dos dados en-
contra-se em forma de tabelas, devemos direcionar a estrutura lógica adequada a esse modelo.
Para isso, não desenvolveremos um diagrama propriamente dito, mas sim um esquema, deri-
vado de um processo de mapeamento. Nesse processo, convertemos as estruturas gráficas do
MER para as estruturas físicas das tabelas.
Os passos básicos para o processo de mapeamento do modelo relacional, geralmente, são
apresentados na disciplina Banco de Dados.
A estrutura das tabelas para o caso do sistema de gestão escolar, após o mapeamento,
será a seguinte (foram colocados poucos atributos, apenas para ilustrar o exemplo):
a) Usuários = {Código do usuário, nome do usuário, login, senha, perfil do usuário}
b) Cursos = {Código do curso, nome do curso}
c) Turmas = {Código da turma, Ano, Semestre, Data de início, Código do Curso, Código
do Professor}
d) Código do professor – chave estrangeira, referência tabela professores
e) Professores = {Código do professor, nome do professor}
© U2 – O Modelo Essencial 61

f) Alunos = {Código do Aluno, nome do aluno, endereço, telefone}


g) Matrículas = {Código da matrícula, Nota 1, Nota 2, Nota Supletiva, Faltas Mês 1, Faltas
Mês 2, Faltas Mês 3, Faltas Mês 4, Código do aluno, Código da turma}
h) Código do aluno – chave estrangeira, referência tabela alunos
i) Código da turma – chave estrangeira, referência tabela turmas
j) Mensalidades = {Código da mensalidade, número da parcela, data de recebimento,
valor recebido, Código do aluno, Código da turma}
k) Código do aluno – chave estrangeira, referência tabela alunos
l) Código da turma – chave estrangeira, referência tabela turmas
É bom deixar claro que a solução da armazenagem de dados de faltas e notas na tabela
matrícula é apenas uma possibilidade. É possível que outro analista olhe para o problema de
forma diferente e proponha outras soluções.
É recomendável que o analista sempre examine outras possíveis soluções antes de finali-
zar o projeto da base de dados do sistema. Muitas vezes, a experiência acumulada pode ajudá-lo
a decidir pela melhor opção.

Normalização de dados
A normalização de dados é um processo de aplicação de regras para derivação de tabelas,
que tem dois objetivos principais:
• Garantir a integridade dos dados, evitando que informações sem sentido sejam inseri-
das;
• Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo a redundân-
cia e permitindo a evolução do banco de dados com o mínimo de efeito colateral.
A melhor hora de normalizar é, imediatamente, depois de projetar tabelas e ter tudo dia-
gramado, pois é neste momento que se detectam problemas e que é possível verificar mais
prontamente em que local a normalização precisa ocorrer. Os benefícios dessa técnica são:
• Flexibilidade: adaptação a demandas diferenciadas, à expansão e redução etc.; diminui
restrições de uso e torna as estruturas de dados e de processos independentes dos
limites rígidos.
• Integridade: aumento da "qualidade" dos dados (atualização, veracidade, fidelidade,
acuracidade etc.).
• Economia: nas estruturas de armazenamento.
A normalização também pode ser realizada em documentos coletados na análise, ajudan-
do o analista a identificar corretamente todas as tabelas necessárias para o armazenamento
dos dados. A normalização não é foco do nosso estudo, é apenas uma das técnicas de análise e
projeto de dados.

O Dicionário de Dados
Ao utilizarmos a Análise Essencial, produzimos uma série de representações gráficas para
simbolizar os componentes do sistema: entidades externas, processos, fluxos de dados e depó-
sitos de dados. Uma vez que os componentes foram identificados e representados, é preciso
descrevê-los em um dicionário.

Claretiano - Centro Universitário


62 © Análise e Projeto de Sistemas

O Dicionário de Dados é um repositório de informações sobre os componentes do sistema.


Essas informações são organizadas por meio de uma linguagem padronizada para os elementos
de dados do sistema, contendo definições precisas e detalhadas. Ele é fundamental, embora,
muitas vezes, a sua importância seja desprezada.
A necessidade do Dicionário de Dados é fundamentada no significado das palavras, como
em qualquer outro dicionário. Na análise, ele servirá como guia para o entendimento dos detalhes
do sistema. Para descrever os componentes do sistema, adota-se uma linguagem apropriada.
Os trabalhos de Gane e Sarson (1983) e DeMarco (1989) propuseram padronizações de
dicionários. Pompilho (2002) apresenta uma combinação delas para a descrição dos fluxos de
dados. Para a descrição de depósitos de dados, ele sugere a estrutura proposta pela notação de
mapeamento do Modelo Entidade-Relacionamento para o modelo relacional.
Um dicionário de dados para a modelagem lógica e conceitual de dados de um sistema
poderia seguir a notação padrão apresentada a seguir:

Entidade
• Depósito de dados: nome do conjunto de entidades.
• Descrição sumária: descrição textual objetiva.
• Estrutura de dados: seguir a notação do mapeamento do Modelo Entidade-Relaciona-
mento para o modelo relacional.

Exemplo:
a) Depósito de dados: aluno.
b) Descrição sumária: entidade que representa o conjunto de pessoas que se matriculam
nos cursos da instituição educacional.
c) Estrutura de dados: aluno = {código do aluno, nome do aluno, CPF, data de nascimen-
to, estado civil, código de desconto}.
d) Código de desconto: chave estrangeira referenciando tabela desconto, campo código
de desconto.

Atributos
Para a descrição dos atributos, a estrutura de um quadro ou tabela pode ser de grande
ajuda. O quadro, a seguir, é apenas uma sugestão. Os campos podem ser modificados de acordo
com os critérios do analista.
Os campos de informação para um atributo em um dicionário de dados são:
a) nome do atributo;
b) é atributo chave? Primária ou estrangeira?;
c) descrição;
d) tipo de dado;
e) tamanho;
f) formatação;
g) máscara;
h) domínio;
i) é obrigatório?
© U2 – O Modelo Essencial 63

Veja um exemplo de utilização deste quadro apresentado a seguir.

Quadro 2 Exemplo de representação de um atributo em um Dicionário de Dados.


CHAVE? OBRIGATÓRIO?
NOME DO FORMATAÇÃO/
PRIMÁRIA/ DESCRIÇÃO TIPO DE DADO TAMANHO DOMÍNIO
ATRIBUTO MÁSCARA SIM/NÃO
ESTRANGEIRA
Armazena
Código do o Registro
Primária Autonumeração - - - Sim
aluno Acadêmico
do aluno
Solteiro,
Situação
casado,
Estado civil - civil do Alfanumérico 10 - Sim
divorciado,
aluno
viúvo
Data de
Data de
- nascimento Data - 99/99/9999 - Sim
nascimento
do aluno

Os tipos de dados podem variar de acordo com o Sistema Gerenciador de Banco de Dados
(SGBD). Por isso, ao definir o SGBD a ser utilizado, realize um breve estudo sobre os seus tipos,
suporte às formatações, máscaras, domínios etc.

Diagrama de Fluxo de Dados


Vamos explorar uma das três principais ferramentas de modelagem gráfica da Análise
Estruturada, componente da Análise Essencial: o Diagrama de Fluxo de Dados ou DFD. Como
vimos anteriormente, no Diagrama de Contexto apresentado nesta unidade, um DFD é uma
representação gráfica do modelo funcional de um sistema, abstraindo e representando um sis-
tema como uma rede de funções ou processos interligados, que são executados em decorrência
dos estímulos gerados pelas necessidades de seus usuários.
Um DFD deve ser acompanhado da descrição de cada função e das suas interfaces. É como
se esta ferramenta de modelagem permitisse ao analista a compreensão de um sistema como
uma rede de processos funcionais, interligados por "dutos" e "tanques de armazenamento" de
dados (YOURDON, 1990).
A modelagem de um sistema em Diagramas de Fluxo de Dados permite que sejam respon-
didas questões do tipo:
a) Que tipo de trabalho o sistema realiza?
b) Que funções o sistema deve executar?
c) Quais são as interações entre os sistemas?
d) Quais as transformações que o sistema deve executar?
e) De onde vêm os dados e para onde vão as saídas de processamento?
A modelagem orientada pelo fluxo de dados continua a ser uma das notações de análise
mais amplamente utilizadas atualmente (PRESSMAN, 2006). Os componentes de um DFD são
quatro:
a) Entidades externas;
b) Fluxos de dados;
c) Funções ou processos;
d) Depósitos de dados.

Claretiano - Centro Universitário


64 © Análise e Projeto de Sistemas

Partiremos do princípio de que um sistema é um conjunto de componentes dinâmicos que


reagem a estímulos por meio de respostas para compreender a integração desses componentes
no modelo. Dentro desse contexto, o DFD proporciona uma visão de entrada-processo-saída de
um sistema. Os estímulos são produzidos por entidades externas por meio de fluxo de dados. O
sistema reage a esses estímulos por meio de seus processos, que realizam atividades nas quais,
muitas vezes, armazenam e recuperam dados de estruturas ou depósitos especiais.
Fluxo de entrada
Entidade
Externa
Depósito de
Fluxo de Processo Dados
saída

Figura 6 Elementos gráficos do Diagrama de Contexto.

Os DFDs modelados de um sistema descrevem quais são, ou deveriam ser, as atividades


que ocorrem para completar um processo empresarial ou executar uma tarefa da empresa,
mas não como essas atividades devem ser realizadas. Em outras palavras, os DFDs mostram a
sequência lógica de associações e atividades, não os processos físicos (STAIR, 1998).
A seguir, você vai estudar cada um desses componentes e compreender como eles podem
compor a visão funcional de um sistema.

Componentes de um Diagrama de Fluxo de Dados


Uma Entidade Externa, também conhecida como terminador de processo, é um elemen-
to do ambiente que atua como fonte ou destino de dados e informações que entram ou saem
do sistema.
Usualmente, uma Entidade Externa é uma pessoa ou um grupo de pessoas. Pode ser ainda
uma organização externa ou mesmo um grupo ou setor dentro da mesma empresa ou organiza-
ção na qual o sistema está sendo modelado, porém fora do controle do sistema. Também pode
ser outro sistema com o qual o nosso sistema modelado se comunicará.
Por exemplo, ao estudarmos um pequeno sistema de controle de estoque, é comum en-
contrarmos outros sistemas de processamento de transações que enviam e recebem dados, tais
como: compras, contas a pagar, vendas etc. As entidades externas podem aparecer mais de uma
vez em um mesmo diagrama.
Uma Entidade Externa é graficamente representada por um retângulo. Exemplos de enti-
dades para a Escola de Línguas Fale Fácil estão apresentados na Figura 7.

Secretária Diretor Aluno

Figura 7 Exemplos de entidades externas.

Os fluxos de dados são compreendidos como condutos que levam dados e informações
de um ponto do sistema para outro. Eles mostram como os dados fluem por meio do sistema,
indicando o trajeto percorrido, por exemplo, e a lógica de processamento do sistema.
Os Fluxos de Dados são representados, graficamente, por setas, que podem ser retas ou
curvadas, mas podem ser setas com pontas duplas.
© U2 – O Modelo Essencial 65

Exemplos de Fluxos de Dados para a Escola de Línguas Fale Fácil estão apresentados na
Figura 8.
Dados Aluno Dados Fechamento Dados Aluno

Confirmação ou rejeição de dados Confirmação ou rejeição de emissão de Confirmação ou rejeição de emissão


aluno relatório de fechamento de boletim de aluno

Figura 8 Exemplos de fluxos de dados.

O processo é o componente mais importante de um DFD. É a partir dele que as entradas


são transformadas nas saídas desejadas, ou seja, na resposta esperada ou, então, em subpro-
dutos importantes para a produção da resposta esperada. Em outras palavras, o processo re-
presenta o componente do sistema que processa dados de entrada em saídas esperadas pelos
usuários.
O processo é denominado ou descrito como uma única palavra ou sentença simples, de
modo que esta descreva o que o processo faz ou deve fazer, como, por exemplo: cadastrar alu-
no, calcular desconto sobre matrícula, emitir recibo etc.
Os processos são representados, graficamente, por círculos e devem conter uma numera-
ção sequencial indicativa. Na figura a seguir estão apresentados exemplos de processos para a
Escola de Línguas Fale Fácil.

1. 2. Emitir 3. Emitir
Cadastrar relatório de boletim de
aluno fechamento aluno
de caixa

Figura 9 Exemplos de processos.

Um depósito de dados representa uma estrutura na qual dados serão armazenados ou


estarão em repouso, e, portanto, serão recuperados para que haja o processamento requeri-
do. Um depósito pode ser consultado ou pode receber novos dados, porém, não pode exercer
nenhuma ação por si próprio. Quando a ponta da seta do fluxo de dados que sai do processo
aponta para o depósito, é sinal de inclusão, alteração ou exclusão de dados. Quando a seta sai
do depósito e aponta para o processo, é sinal de consulta ou leitura de dados.
Os depósitos de dados são representados graficamente por duas linhas ou barras parale-
las, para distingui-los de entidades externas.
Exemplos de depósitos de dados para o exemplo da Escola de Línguas Fale Fácil estão
apresentados na Figura 10.

Aluno Caixa Matrícula

Figura 10 Exemplos de depósitos de dados.

A Figura 11 apresenta um DFD para inserção de dados de aluno no exemplo da Escola de


Línguas Fale Fácil.

Claretiano - Centro Universitário


66 © Análise e Projeto de Sistemas

1 ccc
Dados Aluno
Secretária Cadastrar Aluno
Aluno

Confirmação ou
Rejeição de
cadastro de aluno

Figura 11 Exemplos de DFD para um processo de cadastro de alunos.

Diretrizes para a elaboração de Diagramas de Fluxo de Dados


Ao elaborar um Diagrama de Fluxo de Dados, o analista deve ter cuidado para não cons-
truir um diagrama inconsistente. Dessa forma, torna-se necessário seguir alguns princípios, tais
como:
a) Descobrir quais são as funções do sistema, quais são as entidades externas que as
utilizam e quais os fluxos principais de entradas e saídas de dados;
b) Escolher nomes significativos para processos, fluxos, depósitos de dados e entidades
externas;
c) Numerar os processos;
d) Refazer os DFDs tantas vezes quanto forem necessárias;
e) Evitar DFDs complexos demais.
Acompanhe atentamente, a seguir, as regras de construção que não são permitidas:
1) Processos com apenas fluxos de entrada:

2) Processos com apenas fluxos de saída:

3) Depósitos de dados apenas com leitura:

4) Depósitos de dados apenas com escrita (armazenamento):


© U2 – O Modelo Essencial 67

5) Fluxos de dados entre entidades externas:

Alunos Diretor

Níveis nos Diagramas de Fluxo de Dados


A Análise Estruturada propõe, como abordagem de estudo, o particionamento do sistema
do tipo Top-down (de cima para baixo), ou seja, a partir do Diagrama de Contexto decompõe-se
o sistema em DFDs de níveis hierárquicos mais baixos, até que possamos chegar aos processos
mais elementares.
Outra abordagem também possível de ser utilizada é chamada de Bottom-up, de baixo
para cima, funcionando de maneira oposta à abordagem Top-down.
A abordagem da Análise Essencial que propõe o particionamento por eventos "essenciais"
do sistema é vista como Middle-out, e pode levar o analista diretamente a um nível intermediá-
rio no qual, usualmente, podem aparecer algumas funções primitivas.
Para compreender o sistema, o analista desenvolve uma série de níveis hierárquicos, de
forma que cada nível oferece, sucessivamente, mais detalhes sobre uma arte do nível que lhe
seja superior. Trata-se de uma abordagem de refinamento.
O analista produz uma série de DFDs e, dentre eles, no nível hierárquico mais alto, está
o Diagrama de Contexto, e, no nível mais inferior, estão os processos primitivos da atividade
essencial. O objetivo de se chegar a um processo elementar é poder especificá-lo em uma lin-
guagem algorítmica mais perto do código a ser construído.

Diagrama de Fluxo de Dados de nível zero


O DFD de nível zero representa o nível imediatamente abaixo do Diagrama de Contexto.
Ao modelarmos um sistema a partir da identificação das atividades essenciais, obtemos, no dia-
grama de nível zero, um diagrama que poderia ser o nível intermediário.
Para obter o DFD de nível zero, o Analista de Sistemas deve verificar se as funções es-
senciais identificadas a partir das interações do sistema com as entidades externas podem ser
agrupadas.
Para ilustrar o processo, vamos imaginar o seguinte Diagrama de Contexto para um siste-
ma hoteleiro.
O gerente cadastra quartos. O atendente cadastra clientes, efetua reservas e cancelamen-
tos. O sistema, automaticamente, realiza todos os dias, ao meio-dia, o cancelamento pelo não
comparecimento dos clientes em reservas não canceladas.
A Figura 12 apresenta o Diagrama de Contexto para esse sistema.

Claretiano - Centro Universitário


68 © Análise e Projeto de Sistemas

tes

Atendente

Solicita
Reserva de
Quarto Mensagem de
Cconfirmação ou
Rrejeição

Solicita Cadastro
de Cliente

Atendente

Mensagem de Sistema Mensagem de


Cconfirmação ou Hotel Cconfirmação ou
Rrejeição Rrejeição

Atendente
Solicita
Mensagem de Solicita
Cadastro
Cconfirmação ou Cancelamento
de Quarto
Rrejeição de Reserva

Gerência

Figura 12 Diagrama de Contexto para um sistema hoteleiro.

Ao decompor o Diagrama de Contexto, nos deparamos com a modelagem de cinco proces-


sos para responder aos estímulos das entidades externas. Esse DFD é chamado de DFD prelimi-
nar. O diagrama resultante dessa modelagem está apresentado na Figura 13.

Atendente

Atendente

4. Cancelar
3. Reservar Reserva
Gerência
Quarto

5. Cancelar
1. Cadastrar não
Quarto Compare-
cimento
Reservas

Quartos
Clientes

2. Cadastrar
Cliente
Atendente

Figura 13 DFD preliminar para o sistema Hotel.

DFD_______________________________________________________________________
Procure não "criar" o hábito de cruzar fluxos, evitando isso sempre que possível.
____________________________________________________________________________________

Ao estudar o diagrama preliminar, percebemos que os processos 1, 3, 4 e 5 dizem respeito


a um macroprocesso de negócio que poderia ser chamado de "Tratar Reservas". O processo 2
poderia ser chamado de "Tratar Cliente".
© U2 – O Modelo Essencial 69

Então poderíamos desenhar, novamente, o DFD, agora com os novos "macroprocessos"


identificados. Esse novo diagrama é o nosso DFD de nível zero. Sua representação gráfica está
apresentada na Figura 14.

Atendente

1. Tratar
Cliente
(2)

Clientes Reservas Quartos

2. Tratar
Reservas
(1, 3, 4, 5)

Atendente
Gerência

Figura 14 DFD de nível zero para o sistema Hotel.

Para finalizar, podemos considerar que o DFD preliminar é desenvolvido apenas com o ob-
jetivo de agrupar em macrofunções as funções decompostas a partir do Diagrama de Contexto.
Isso pode ser realizado antes da construção do Diagrama de Contexto.
Pompilho (2002) apresenta uma série de orientações gerais sobre a orientação do layout
de um DFD. As principais recomendações são:
1) O fluxo geral dos dados deve seguir uma orientação de cima para baixo e da esquerda
para a direita.
2) As entidades externas devem ficar, de preferência, nas bordas do desenho.
3) Os depósitos de dados devem estar posicionados:
a) Se forem de entrada, à esquerda ou acima da função que recebe seus dados.
b) Se forem de saída, à direita ou abaixo da função que lhe fornece dados.
4) Os processos podem estar ligados:
a) Diretamente, por meio de fluxos de dados.
b) Indiretamente, com um depósito de dados entre eles.
c) O processo de origem deve ficar à esquerda ou acima do processo de destino.

Diagramas de fluxo de dados dos processos primitivos


Quando se identificam os eventos de interesse em um ambiente de um sistema, encon-
tram-se, em consequência, as atividades ou funções essenciais do sistema.

Claretiano - Centro Universitário


70 © Análise e Projeto de Sistemas

Como vimos anteriormente, para cada evento identificado será necessário especificar uma
função chamada "essencial", que executará todas as ações que constituem a resposta completa
do sistema ao evento em questão.
As funções essenciais do sistema constituem os níveis mais baixos de um Diagrama de
Fluxo de Dados.
Seguindo o nosso exemplo do sistema Hotel, vamos estudar a função essencial Tratar
Cliente. Essa função é, na realidade, o processo de cadastramento de cliente. Todavia, esse
processo não é apenas o cadastramento. Trata-se de uma função que pode ser subdividida em
inclusão, alteração e exclusão. Para a realização dessas funções, usualmente será necessário
algum tipo de consulta, por exemplo, para localizar um conjunto de dados a ser excluído ou
uma listagem de todos os dados já cadastrados. Essa função também poderia ser chamada de
"Manter dados de Clientes".
Portanto, em um sistema que armazena dados, cinco tipos de funções podem ser previs-
tas. Essas funções são os processos primitivos, ou seja, abaixo delas não é possível haver decom-
posição. O diagrama para esta função está apresentado na Figura 15.
Solicita Inclusão
de Cliente 1.1 Incluir
Cliente

Solicita Alteração
de Cliente 1.2 Alterar
Cliente

Atendente Solicita Inclusão


de Cliente 1.3 Excluir Clientes
Cliente

Solicita Consulta
a Cliente
1.4 Consultar
Cliente

Solicita Listagem
de Cliente

1.5 Listar
Clientes

Figura 15 DFD dos processos primitivos da atividade essencial cadastrar cliente para o sistema Hotel.

O processo "Tratar Reservas", na Figura 14, deverá ser expandido em um subnível que
apresente os processos: cadastrar quarto; reservar quarto; cancelar reserva e cancelar não com-
parecimento, conforme demonstra a Figura 16, a seguir.
Note, no DFD "Tratar Reserva", que o processo "Cadastrar Cliente" acessa o depósito de
dados de Clientes e, portanto, continua indicado como entrada de fluxo de dados sem que seu
processo seja desenhado.
© U2 – O Modelo Essencial 71

Solicita
Manutenção em
Reservas
Atendente

Solicita
Manutenção em
Quartos 3. Manter
Gerência Dados
Reservas
4. Cancelar
não
Compare-
1. Manter cimento
Dados
Quartos

Reservas

Clientes
Quartos

2. Cadastrar
Cliente

Figura 16 DFD do subnível "Tratar Reserva" para o sistema Hotel.

O diagrama foi redesenhado e dois processos foram agregados em "Manter Dados Reser-
vas". A numeração do processo "Cancelar não Comparecimento" foi alterada de 5 para 4.
O processo "Cadastrar Quarto" pode ser considerado uma atividade essencial, pois integra
o conjunto de funções para manter dados de quartos.
O processo "Reservar Quarto" também é uma atividade de inclusão de dados, e o proces-
so "Cancelar Reserva", uma atividade de alteração de dados. Portanto, podem ser consideradas
funções para manter dados de reservas.
O processo "Cancelar não Comparecimento" é outra função de alteração de dados de re-
serva gerada por um evento orientado a tempo, e será especificada separadamente.

Derivação integrada do modelo de funções


O estudo da modelagem de fluxo de dados revelou que os sistemas tratam do armazena-
mento e recuperação de dados a partir de algum tipo de estrutura, ainda não definida formal-
mente, mas citada no modelo como depósito de dados. Paralelamente a essa modelagem, de-
senvolvemos um diagrama entidade-relacionamento e definimos formalmente, as estruturas de
dados em tabelas para o sistema. Portanto, esses modelos, com objetivos distintos, têm algum
tipo de integração, e o Analista de Sistemas pode utilizar essa integração a seu favor.
A modelagem de fluxo de dados revela os depósitos que devem ser considerados no dia-
grama entidade-relacionamento. Cada depósito de dados pressupõe que haja atividades de ma-
nutenção nos dados que serão armazenados.
Os relacionamentos entre os conjuntos de entidades também revelam funções pertinen-
tes ao sistema.
Assim, à medida que incluímos no diagrama entidade-relacionamento as classes de enti-
dades pertinentes a cada evento, devemos, paralelamente, incluir no DFD as funções correspon-
dentes a cada evento.
Lembre-se de que as funções de um DFD sempre são responsáveis por criar entidades,
mudar o estado delas ou estabelecer relacionamentos entre elas. Portanto, um DFD pode ser
utilizado, também, como caminho possível para se obter o modelo de dados.

Claretiano - Centro Universitário


72 © Análise e Projeto de Sistemas

Dessa forma, a integração pode ser utilizada para derivação, checagem e aperfeiçoamento
dos modelos.

Especificações dos Processos


Quando o Analista de Sistemas modela um sistema e chega aos processos primitivos, ele
está se aproximando da reta final da análise. Para tanto, é preciso utilizar uma abordagem que
possa ser verificada e transmitida facilmente aos envolvidos no projeto e, especialmente, aos
programadores. Trata-se da especificação do processo.
Uma especificação de processo, também conhecida como miniespecificação, trata o pro-
cesso em linhas gerais enfatizando os aspectos essenciais, especialmente, aqueles que se refe-
rem às regras do negócio de tal maneira que, se não houver esta especificação, um programador
não construirá satisfatoriamente o programa. Não é o caso de fornecer detalhes de como será
o procedimento de inclusão, alteração, exclusão ou consulta, mas sim da apresentação de uma
síntese do objetivo global do processo, salvo se houver detalhes de implementação proveniente
das regras do negócio. Daí, então, é possível que haja uma miniespecificação mais ampla. O DFD
delimita o contexto da função: com que entidades externas interage? Que depósitos lê/atualiza
e que saídas produz? A especificação diz exatamente o que ele faz.

Regras de negócio____________________________________________
São regras que uma empresa estabelece para o funcionamento de seu negócio e estão classificadas em três tipos,
que são: regras de derivação, regras de integridade e regras de processo (YOURDON, 1990).
___________________________________________________________________________
As especificações de processos representam o maior volume de trabalho minucioso na
construção do modelo de um sistema. Dependendo do porte do sistema, é possível que existam
centenas e até milhares de especificações de processos, e cada uma pode ocupar uma página.
As especificações são importantes porque detalham o comportamento e permitem validar as
entradas, saídas e acessos de cada atividade essencial isoladamente.
As principais técnicas de especificação são:
a) Português Estruturado.
b) Pseudocódigo.
c) Tabela de decisão.
d) Árvore de decisão.
Estudaremos essas técnicas a seguir.

Português Estruturado
Essa técnica é uma versão adaptada do nosso idioma, com ênfase em verbos – de pre-
ferência no modo imperativo –, acrescida de construções comuns das estruturas de controle
existentes nas linguagens de programação, tais como: sequências, decisões e repetições.
Ao mesmo tempo em que pode estabelecer um canal de comunicação de alto nível com o
usuário, serve como ponto de partida para a codificação em linguagem de programação.
O Português Estruturado é orientado para procedimentos e pode utilizar termos familiares
ao usuário, tais como a linguagem do negócio da empresa. As principais estruturas utilizadas
estão apresentadas no Quadro 3.
© U2 – O Modelo Essencial 73

Quadro 3 Principais estruturas do Português Estruturado.


SINTAXE PORTUGUÊS ESTRUTURADO

Obtenha, calcule, coloque, copie etc.


Sequência de instruções
Para cada ... faça o que segue
Repetição de instruções Se ... senão, faça o que segue
Caso 1: ... faça o que segue
Seleção de instruções Caso 2: ... faça o que segue
Caso 3: ... faça o que segue

Veja, a seguir, um exemplo de especificação de um processo para emitir o aviso da situa-


ção do aluno. Nele, estão apresentados o DFD e as estruturas mapeadas das tabelas.
Função: emitir aviso da situação do aluno.
Objetivo: emitir aviso a ser enviado para o aluno, indicando o desempenho em cada disci-
plina, e a avaliação global, que indica a sua situação em relação ao período cursado.
Lembre-se de que, ao especificar uma função, é fundamental que você defina com clareza
o objetivo dela.
Observe, a seguir, o DFD do processo primitivo.

Solicita listagem
de situação de
alunos
Secretária

Relatório
emitido ou
Emitir
rejeitado
aviso
situação
aluno

Alunos
Avaliações

Disciplinas

Figura 17 DFD do processo primitivo – Emitir aviso de


situação do aluno.

Tabelas:
Alunos = {código da matrícula do aluno, nome do aluno, endereço do aluno}
Disciplina = {código da disciplina, nome da disciplina, conteúdo programático}
Avaliações = {código da matrícula do aluno, código da disciplina, média final}
Especificação:
Para cada aluno no arquivo de alunos:
1) Coloque a matrícula, o nome e o endereço do aluno no formulário de aviso.
2) Para cada código da disciplina cursada pelo aluno, existente no arquivo de avalia-
ções:
a) Obtenha, a partir do arquivo de disciplinas, o nome da disciplina.
b) Obtenha, a partir do arquivo de avaliações, a média final do aluno na disciplina.

Claretiano - Centro Universitário


74 © Análise e Projeto de Sistemas

c) Coloque, no formulário de aviso o código, o nome e a média final da disciplina cursada


pelo aluno.
3) Calcule o total de disciplinas em que o aluno obteve média final menor que 5.
a) (CASO 1) nenhuma disciplina com média final menor do que 5.
• Coloque no formulário a expressão "APROVADO".
b) (CASO 2) mais de três disciplinas com médias finais menores que 5.
• Coloque no formulário a expressão "REPROVADO".
c) (CASO 3) menos de quatro disciplinas com médias finais menores que 5.
• Coloque no formulário a expressão "EM RECUPERAÇÃO".

Pseudocódigo
Uma forma textual alternativa e mais popular de se descrever especificações, quase idên-
tica ao português estruturado, porém mais próxima das linguagens de programação, é a utili-
zação do pseudocódigo. Trata-se de uma abordagem de especificação mais orientada para a
implementação, chegando a ter a sintaxe que lembra uma linguagem de programação.
Portanto, ao usar essa técnica, o analista tem como principal objetivo facilitar a programa-
ção do sistema, utilizando:
a) Verbos: LER, OBTER, IMPRIMIR, GRAVAR etc.;
b) Substantivos: elementos do dicionário de dados;
c) Estruturas de controle: SE, ENQUANTO, REPETIR, CASO;
d) Operadores de relação: IGUAL, MAIOR QUE, MENOR QUE etc.
O pseudocódigo é utilizado no ensino de lógica e algoritmos em disciplinas de introdução
à programação estruturada. Um resumo das principais estruturas de pseudocódigo está apre-
sentado no Quadro 4.
Quadro 4 Principais estruturas de pseudocódigo.
Estrutura de SEQUÊNCIA Estrutura de DECISÃO – SE
INÍCIO INÍCIO
Ação 1 Ação 1
Ação 2 SE Condição C1
Ação 3 ENTÃO
FIM. Ação 2
SENÃO
Ação 3
FIM_SE
Ação 4
FIM.

Estrutura de DECISÃO – SELEÇÃO Estrutura de REPETIÇÃO – ciclos contados


INÍCIO INÍCIO
ESCOLHA Opção Ação 1
CASO Opção = 1 : Ação 1 PARA Var_I de 1 ATÉ 4 FAÇA
CASO Opção = 2 : Ação 2 Ação 2
CASO Opção = 3 : Ação 3 Ação 3
CASO CONTRÁRIO : Ação 4 FIM_FAÇA
FIM_ESCOLHA FIM.
FIM.

Estrutura de REPETIÇÃO – REPITA Estrutura de REPETIÇÃO – ENQUANTO


INÍCIO INÍCIO
Ação 1
REPITA Ação 1
Ação 2 ENQUANTO Condição C1
ATÉ QUE Condição C1 Ação 2
FIM_REPITA FIM_ENQUANTO
Ação 3 Ação 3
FIM FIM.
© U2 – O Modelo Essencial 75

Muitos autores propuseram linguagens de miniespecificações influenciados pela fase es-


truturalista da análise e projeto de sistemas. Todavia, é perfeitamente livre a criação de uma
miniespecificação em outros formatos, propiciando formas um pouco mais abstratas sem a ideia
de uma estruturação.
Concluindo, a atividade de escrever especificações de processos pode servir como um
teste de checagem para os DFDs. Ao especificar um processo, você pode descobrir que a neces-
sidade de fluxos de dados de entrada adicionais não foi mostrada no DFD.
Ao escrever a especificação, pode surgir a necessidade de mais funções. Portanto, a espe-
cificação de processos é uma atividade que revela a visão detalhada de um sistema e que, tam-
bém, integrante aos outros modelos já desenvolvidos: o Diagrama Entidade-Relacionamento e
o Diagrama de Fluxo de Dados.

Tabela de decisão
Uma tabela de decisão é uma ferramenta não procedural que permite especificar proces-
sos que produzem uma saída ou ação dependendo da avaliação de condições complexas. Trata-
se de uma maneira de expressar, em forma de tabela, qual conjunto de condições é necessário
existir para que um determinado conjunto de ações seja executado (POMPILHO, 2002).
A estrutura de uma tabela de decisão é composta por:
a) seção de condições – superior esquerdo;
b) seção de ações – inferior esquerdo;
c) entrada de condições – superior direito;
d) entrada de condições – inferior direito.
A Tabela 1 mostra um exemplo para uma situação de condições de realização de diversos tipos
de exames, em relação à idade e ao sexo de uma pessoa. Ao efetuar a leitura por colunas, é possível
compreender, claramente, todas as combinações de situações possíveis.
Tabela 1 Exemplo de tabela de decisão.
CONDIÇÕES 1 2 3 4
Idade > 21 S S N N
Sexo M F M F
AÇÕES
Exame físico simples X
Exame físico completo X X
Exame prático X
Exame psicológico X

Para criar uma tabela de decisão, é necessário que você siga os seguintes passos (YOURDON,
1990):
a) Identificar todas as condições ou variáveis na especificação;
b) Identificar todos os valores possíveis para cada condição ou variável;
c) Calcular o número de combinações possíveis;
d) Identificar as ações;
e) Criar uma tabela de decisões vazia;
f) Preencher as condições e ações na parte esquerda da tabela;
g) Especificar as ações adequadas de acordo com as condições especificadas na coluna;

Claretiano - Centro Universitário


76 © Análise e Projeto de Sistemas

h) Identificar omissões e ambiguidades existentes na especificação do problema e discu-


ti-las com o usuário.

Árvore de decisão
Uma árvore de decisão é a representação de uma tabela de decisão. Essa representação é
especialmente útil quando nem todas as combinações de condições são possíveis. Por ser uma
ferramenta gráfica, torna mais fácil a compreensão e discussão de possibilidades de decisão e,
também, permite representar tomadas de decisão complexas.
A árvore de decisão, conforme demonstrada na Figura 18, apresenta situação de condi-
ções para realização de diversos tipos de exames, em relação à idade e ao sexo de uma pessoa,
já modelada na tabela de decisão (Tabela 1).

Fonte: Yourdon (1990, p. 271).


Figura 18 Exemplo de Árvore de Decisão.

Para criar uma árvore de decisão, é necessário que você siga os seguintes passos (YOURDON,
1990):
a) Identificar as condições;
b) Identificar os valores de cada condição;
c) Determinar o número de regras do problema (ramos da árvore);
d) Identificar as ações;
e) Fazer as simplificações necessárias (podar a árvore).

Modelagem comportamental e modelagem de estados


Há determinados tipos de sistemas em que a representação em diagramas de fluxos de
dados não é adequada para a modelagem. Nesses sistemas, é necessário modelar o compor-
tamento, que depende de tempo ou estado de execução. Os sistemas típicos dessa categoria
são os sistemas de tempo real. Esses sistemas interagem com fontes de dados externas de alta
velocidade e devem produzir respostas e dados de saída rapidamente, para interagir com o
ambiente externo. Exemplos de sistemas de tempo real são: sistemas de controle de processos,
sistemas de controle militares, sistemas de navegação em automóveis etc.
A modelagem é realizada por meio do estado em que o sistema pode estar. Um estado é uma
situação em que o sistema se encontra e que pode durar por um determinado período de tempo.

8. FERRAMENTAS AUTOMATIZADAS DE APOIO À ANÁLISE ESTRUTURADA


As ferramentas de modelagem de sistema fornecem ao Analista de Sistemas a habilidade
de modelar todos os elementos, baseado em computador, usando uma notação que é específi-
ca, de acordo com cada ferramenta.
© U2 – O Modelo Essencial 77

É possível encontrar ferramentas específicas para determinadas técnicas, como, por exem-
plo, para a Modelagem Entidade-Relacionamento e, ainda, ferramentas que integram mais de
uma técnica. Além disso, é comum, também, encontrarmos ferramentas com características
CASE.
O uso de uma ferramenta para modelagem pode facilitar o trabalho do analista na dia-
gramação dos modelos, agregando funcionalidades de edição que melhoram a produtividade e
evitando o uso de ferramentas gráficas de editores de texto.
A escolha de uma determinada ferramenta deve ser pautada pelos recursos que ela ofere-
ce e pela relação custo-benefício pretendida.
Veja, no quadro a seguir, uma breve lista de ferramentas disponíveis. Você poderá encon-
trar várias outras listas na internet.
Quadro 5 Lista de ferramentas na internet.
LISTA DE FERRAMENTAS DISPONÍVEIS NA INTERNET

Ferramenta proprietária, agora rebatizada com o nome de Toad™ Data Modeler. Integra
modelagem case para bases de dados e, também, diagramas de fluxo de dados. A versão de
CaseStudio
demonstração permite a criação de pequenos sistemas, com até cinco tabelas. Além disso,
não permite salvar seu trabalho. Disponível em: <http://www.casestudio.com/enu/default.
aspx>. Acesso em: 01 jan. 2010.

Gliffy Ferramenta livre em Web 2.0.


Disponível em: <http://www.gliffy.com/>. Acesso em: 01 jan. 2010.
Ferramenta proprietária.
Smartdraw
Disponível em: <http://www.smartdraw.com/specials/erddataflow.asp?id=140186>. Acesso
em: 01 jan. 2010.
Uma ferramenta poderosa da Microsoft, que integra várias ferramentas de modelagem.
MS Visio
Disponível em: <http://office.microsoft.com/pt-br/visio/default.aspx>. Acesso em: 01 jan.
2010.
Case Design Studio Ferramenta livre.
Disponível em: <http://www.cdstudio.nack.com.br/>. Acesso em: 01 jan. 2010.

9. QUESTÕES AUTOAVALIATIVAS
As questões a seguir referem-se aos tópicos estudados nesta unidade, mais especifica-
mente ao Modelo Essencial. Responda às questões e, caso sinta dificuldade ao realizar as ativi-
dades, lembre-se de rever o conteúdo e discuti-lo com seu tutor e colegas.
1) É correto afirmar:
I. Análise Essencial de Sistemas ou Análise e Projeto Estruturados divide o sistema em funções, enquanto no
paradigma da orientação a objetos o sistema é dividido em objetos.
II. O modelo essencial é assim chamado, pois descreve o sistema de maneira independente de restrições
tecnológicas.
III. No modelo essencial considera-se a existência da tecnologia perfeita como, por exemplo, capacidade de
armazenamento de dados infinita e tempo de acesso a dados instantâneo.
IV. O modelo ambiental mostra como o sistema deve reagir internamente a estímulos do ambiente exterior.
V. O modelo comportamental representa a interface do sistema com o mundo exterior, mostrando a intera-
ção do sistema com os elementos externos a ele.
Assinale a alternativa correta:
a) Estão corretas apenas as afirmativas I e III.
b) Estão corretas apenas as afirmativas III, IV e V.
c) Estão corretas apenas as afirmativas I, II e III.
d) Todas as afirmativas estão corretas.
e) Apenas a afirmativa V está incorreta.

Claretiano - Centro Universitário


78 © Análise e Projeto de Sistemas

2) Assinale a alternativa incorreta:


a) A abstração é uma técnica empregada na modelagem de sistemas, onde a realidade do ambiente a ser ana-
lisado deve ser observada e abstraída e, apenas depois disso, dar início ao desenvolvimento do processo de
modelagem.
b) No paradigma da Análise Essencial, o analista se utiliza de ferramentas como o diagrama de fluxo de dados,
diagrama de atividades e dicionário de dados para construir o modelo lógico.
c) O Modelo Essencial do sistema indica o que é necessário ao sistema para ele satisfazer aos requisitos do
usuário, praticamente sem mencionar como o sistema será implementado.
d) Eventos são fundamentais quando se trata de sistemas desenvolvidos sob o paradigma da Análise Essen-
cial.
e) Dois métodos de análise estão envolvidos no modelo essencial: a modelagem de dados e a modelagem
funcional.
3) São objetivos da construção de modelos de sistemas:
a) Focalizar características importantes do sistema, deixando de lado as menos importantes.
b) Discutir alterações e correções nos requisitos do usuário a baixo custo e com mínimo risco.
c) Confirmar a compreensão sobre o ambiente do usuário.
d) Documentar as informações sobre o ambiente do usuário, de forma que projetistas e programadores pos-
sam construir o sistema.
e) Todas as alternativas anteriores.

Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:

1) c.

2) b.

3) e.

10. CONSIDERAÇÕES
Nesta unidade, você teve a oportunidade de estudar as ferramentas de modelagem da
Análise Essencial. A Análise Essencial de sistemas contempla as ferramentas de modelagem que
auxiliam o analista a examinar o sistema, baseado no ponto de vista de funções e dados e in-
cluindo, também, a perspectiva dos controles. A abordagem essencial utiliza ferramentas que
produzem modelos para ajudar a compreender o problema com base em dois enfoques princi-
pais: externo e interno.
Na modelagem ambiental, o sistema é visto como se fosse uma caixa-preta, inserido em
um ambiente dinâmico no qual estímulos de diversos tipos produzem alguma resposta do sis-
tema. A Declaração dos objetivos do sistema é uma declaração textual clara e simples que deli-
mita o problema ou escopo do projeto sem informar detalhes. O Diagrama de Contexto é uma
abstração do sistema e suas interações com seu ambiente, no qual pessoas e outros sistemas
provocam estímulos e esperam respostas. Os estímulos são provocados por eventos que são
categorizados em: orientados a fluxo de dados, orientados a fluxo de controle e temporais. Estes
eventos são o elemento-chave da produção do documento de requisitos e podem ser organiza-
dos em quadros, para facilitar a leitura.
Na modelagem comportamental, o sistema deve ser representado como uma "caixa-bran-
ca", de forma que seja compreendido em detalhes suficientes para que possa ser programado. A
modelagem de dados é um método de análise de sistemas utilizado para criar uma especificação
da estrutura de dados do sistema. Dois níveis de modelagem de dados são produzidos: a mo-
delagem conceitual e a modelagem lógica de dados. A Modelagem Entidade-Relacionamento
apresenta três construtores para a representação da semântica dos dados: entidades, atributos
© U2 – O Modelo Essencial 79

e relacionamentos. O diagrama de estrutura de dados é um esquema que especifica a estrutura


lógica de acordo com a arquitetura de banco de dados selecionada. A normalização de dados
é um processo de aplicação de regras para derivação de tabelas, que pode ajudar o analista a
detectar problemas não percebidos na Modelagem Entidade-Relacionamento. O Dicionário de
Dados é construído para ajudar a descrever e documentar as informações sobre os componen-
tes do sistema.
O Diagrama de Fluxo de Dados é utilizado para apresentar a visão funcional do sistema.
Os principais componentes de um DFD são as entidades externas, os fluxos de dados, os pro-
cessos e os depósitos de dados. Os processos são os elementos mais importantes de um DFD
e representam as transformações que o sistema realiza para produzir as saídas desejadas. A
Análise Essencial propõe o particionamento por eventos essenciais do sistema. A construção da
visão funcional pressupõe a decomposição do Diagrama de Contexto em níveis hierarquicamen-
te inferiores, até que seja possível compreender as funções essenciais do sistema. O modelo
funcional e o modelo de dados podem ser estudados de forma integrada para a compreensão
do sistema. A especificação de processo descreve o processo genericamente, enfatizando os
aspectos essenciais, e pode ser mais voltada ao usuário ou mais voltada à programação. O Por-
tuguês Estruturado é uma forma de especificar um processo utilizando termos familiares ao
usuário. O Pseudocódigo é uma abordagem de especificação mais orientada para a implemen-
tação, podendo ter a sintaxe que lembra uma linguagem de programação. A miniespecificação
pode ser adaptada pelo analista para formas mais livres de estruturação. A tabela de decisão é
uma maneira de expressar um conjunto de condições necessárias a um determinado conjunto
de ações que pode ser executado. Outra forma gráfica para representar grandes conjuntos de
pontos de decisão é a árvore de decisão.
Agora, é importante que você pratique seus conhecimentos com os exercícios propostos .
Lembre-se de que o sucesso de um profissional está na dedicação à prática, que leva ao aperfeiço-
amento de suas habilidades e competências. Dedique algum tempo extra para aprofundar seus
conhecimentos com as leituras das bibliografias indicadas sobre estes assuntos. Sinta-se à von-
tade para explorar sistemas de seu cotidiano com as ferramentas da Análise Essencial e interaja
com o seu tutor para relatar as experiências obtidas.
A Unidade 3 apresentará a você os conceitos da UML – Unified Modeling Language (Lin-
guagem de Modelagem Unificada), apropriada para a definição de modelos quando se trata
de sistemas orientados a objetos. Você será, então, apresentado a outra abordagem de desen-
volvimento de software: a análise e projeto orientados a objetos e, assim, poderá iniciar suas
observações sobre as duas abordagens de desenvolvimento.

11. REFERÊNCIAS BIBLIOGRÁFICAS


DeMARCO, T. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989.
GANE, C.; SARSON, T. Análise estruturada de sistemas. São Paulo: LTC, 1983.
McMENAMIM, S. M.; PALMER, J. F. Análise essencial de sistemas. São Paulo: McGraw-Hill, 1991.
POMPILHO, S. Análise essencial: guia prático de análise de sistemas. Rio de Janeiro: Ciência Moderna, 2002.
PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.
STAIR, R. M. Princípios de sistemas de informação: uma abordagem gerencial. 2. ed. Rio de Janeiro: LTC, 1998.
YOURDON, E. Análise estruturada moderna. Rio de Janeiro: Campus, 1990.

Claretiano - Centro Universitário


Claretiano - Centro Universitário
EAD
Processo de Desenvolvimento
de Software – Modelagem de
Casos de Uso
3

1. OBJETIVOS
• Conhecer a Unified Modeling Language – UML.
• Definir requisitos.
• Conhecer as tarefas relacionadas à etapa da fase de concepção do sistema.
• Conhecer o Modelo de Casos de Uso.
• Descrever e definir Casos de Uso.
• Elaborar o diagrama de Casos de Uso.

2. CONTEÚDOS
• Histórico da UML.
• Visão geral dos diagramas componentes da UML.
• Definição e classificação de requisitos de sistema.
• Atividades da fase de concepção do sistema.
• Modelo de Casos de Uso.
• Descrição de Casos de Uso.
• Diagrama de Casos de Uso.
• Apresentação da ferramenta astah* community para o desenvolvimento do diagrama
de Casos de Uso.
• Exemplo: Sistema Livraria.
82 © Análise e Projeto de Sistemas

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Atente-se para o conceito de Casos de Uso. A modelagem orientada a objetos, com
a utilização da UML, tem nos Casos de Uso a base para o desenvolvimento de seus
principais diagramas.
2) Lembre-se de fazer a leitura dos livros indicados na bibliografia. Isso o ajudará a fun-
damentar conceitos teóricos.
3) Sempre que possível, tente resolver exercícios ou casos propostos nos livros da biblio-
grafia indicada. A prática contínua dos conceitos estudados o ajudará a aperfeiçoar o
desenvolvimento da técnica da modelagem de software.
4) É importante conhecer a maneira como você desenvolve sua prática. Procure pesqui-
sar sempre e interagir com seus colegas e tutor. Cultivar esses hábitos vai ajudá-lo a
ampliar e aprofundar seus conhecimentos.
5) Para obter maiores informações sobre o catálogo de especificações da OMG (Object
Management Group), mais especificamente da UML, acesse o site: <www.omg.org>.
6) Você pode pesquisar na bibliografia sugerida e em sites sobre as diferentes formas de
descrever os Casos de Uso. Verá que, embora possam ser um pouco diferentes umas
das outras, todas têm o mesmo objetivo, que é descrever como os atores interagem
com o sistema na execução de determinada funcionalidade.
7) Se tiver alguma dúvida sobre pacotes de Casos de Uso, faça uma revisão do conteúdo
anteriormente apresentado. Troque informações com seu tutor e com os colegas para
o enriquecimento de seu conhecimento sobre este assunto.
8) Você pode obter maiores informações sobre a ferramenta astah* community, entre
no site: <http://astah.change-vision.com/en/product/astah-community.html>.

4. INTRODUÇÃO À UNIDADE
Na Unidade 2, você conheceu a abordagem de desenvolvimento de software pela análise
essencial e os artefatos gerados, incluindo os diagramas específicos para essa abordagem.
Na Unidade 3, serão apresentadas, detalhadamente, as tarefas relacionadas ao desenvol-
vimento de um sistema. Você verá que cada fase do processo de desenvolvimento gera docu-
mentos do sistema e você terá a oportunidade de conhecê-los.
Nesta unidade você verá, também, uma breve introdução à história da UML.
Todo sistema, independentemente da abordagem utilizada em seu desenvolvimento, pas-
sa por uma série de etapas que compõem o seu ciclo de vida.
Tendo como base as etapas que a Engenharia de Software considera comuns a todos os
sistemas, vamos iniciar pela fase da especificação do sistema. Nessa fase, realizaremos a desco-
berta dos requisitos do sistema. Em seguida, definiremos os Casos de Uso. Na próxima fase, os
Casos de Uso serão descritos e modelados no diagrama de Casos de Uso.
Para facilitar a compreensão dos processos que ocorrem durante o desenvolvimento
do sistema, nesta e nas próximas unidades acompanharemos um exemplo de um sistema de
software educacional e um sistema para livraria.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 83

5. UNIFIED MODELING LANGUAGE – UML


Para melhor compreensão do que é realmente a UML e de como ela é aplicada no desen-
volvimento de software, façamos uma retrospectiva da história do desenvolvimento de software,
mais especificamente da modelagem de sistemas. Segundo Bezerra (2007), o histórico da evolu-
ção das técnicas de desenvolvimento de software pode ser assim resumido:
a) Décadas de 1950 a 1960: os sistemas de software são muito simples. As técnicas de
modelagem utilizadas são, basicamente, os fluxogramas e diagramas de módulos.
b) Década de 1970: surgem computadores mais avançados e, consequentemente, siste-
mas mais complexos. Surge, nesse período, a programação estruturada e, com ela, a
análise e projeto estruturados de sistemas. As técnicas de modelagem basearam-se,
então, na Análise Estruturada de Sistemas (lembre-se da Unidade 2, que aborda essas
técnicas, com a apresentação dos diagramas e ferramentas utilizadas na Análise Estru-
turada, posteriormente conhecida como Análise Essencial de Sistemas).
c) Década de 1980: os computadores tornam-se mais avançados ainda, e mais baratos.
A necessidade por interfaces humano-computador mais sofisticadas permite o desen-
volvimento de sistemas mais complexos. Até por volta de 1985, a Análise Estruturada
se consolida como técnica de modelagem dos sistemas.
d) Início da década de 1990: a Análise Estruturada apresenta algumas dificuldades rela-
cionadas a certos domínios de aplicação. Em resposta a essa dificuldade, surge o novo
paradigma de modelagem de sistemas conhecido como Análise Orientada a Objetos.
e) Final da década de 1990: com o surgimento das linguagens de programação orienta-
das a objetos, conceitos de padrões de projeto, frameworks, entre outros, o paradig-
ma da orientação a objetos alcança sua maturidade.
Conforme podemos observar, o paradigma da orientação a objetos não é tão novo. As
linguagens orientadas a objetos já existem desde a década de 1960. O que aconteceu é que
nessa época a ideia da orientação a objetos não foi bem aceita, e ficou "adormecida" por um
período, até que na década de 1990, com as dificuldades apresentadas na modelagem com a
Análise Estruturada, e com o advento de linguagens orientadas a objetos, como Java e C++, o
novo paradigma se impôs. E hoje, segundo Blaha e Rumbaugh (2006, p. 9) "a tecnologia OO não
pode mais ser considerada uma moda... Ela agora faz parte integrante da ciência da computação
e engenharia de software.".
Entretanto, um problema acontecia nessa época. Era a falta de uma notação padrão para
o desenvolvimento da modelagem dos sistemas. Com a invenção e a utilização da linguagem
de programação orientada a objetos, percebeu-se a necessidade de atualização das técnicas
de análise, que, até então, eram voltadas somente à programação estruturada. As notações
existentes para a modelagem orientada a objetos chegavam a expressar ideias semelhantes,
porém, uma confusão acontecia entre os desenvolvedores, devido à falta de padronização entre
as diferentes notações, levando a uma dificuldade de comunicação.
Como medida para essa diferença de padronização, a OMG (Object Management Group)
solicitou propostas para uma notação padrão de modelagem orientada a objetos.
Várias técnicas foram propostas e os cientistas da computação Grady Booch, James Rumbaugh
e Ivar Jacobson desenvolveram as três metodologias mais conceituadas de modelagens orientadas
a objetos (Booch, OMT e OOSE, respectivamente). No entanto, cada metodologia desenvolvida pos-
suía notações, processos e ferramentas distintas.
Em 1994, Booch e Rumbaugh uniram forças para combinar suas duas metodologias po-
pulares – Booch e OMT. Posteriormente, Jacobson, o criador do método OOSE, reuniu-se a

Claretiano - Centro Universitário


84 © Análise e Projeto de Sistemas

eles. Em 1996, em resposta à solicitação da OMG, foi apresentada a UML (Unified Modeling
Language), desenvolvida por Grady Booch, Jim Rumbaugh e Ivar Jacobson. E, finalmente, em
1997, a OMG aceitou a UML, de forma unânime, como padrão, substituindo as outras nota-
ções.
A UML é, portanto, a junção do que havia de melhor nas três metodologias – Booch, OMT,
OOSE. Além disso, foram incorporados novos conceitos e visões não encontrados em outros
métodos orientados a objeto. Em 2001, a OMG começou a revisar as especificações da UML, em
razão de descobertas de alguns problemas com a UML 1. Em 2004, foi aprovada a versão 2.0.
Atualmente, sua versão é a 2.2, e existe uma versão 2.3 beta.
A UML é uma linguagem visual, utilizada para modelar os sistemas orientados a objetos. É
uma linguagem de notação, pois define elementos gráficos (por isso é dita visual) para a elabo-
ração dos diversos diagramas que a compõem. Cada diagrama possui uma sintaxe (corresponde
ao "como desenhar um elemento") e uma semântica (define o significado do elemento). Cada
diagrama revela uma visão que se pode ter do sistema.
Lembre-se de que um modelo é uma abstração de alguma coisa que queremos entender
antes de construí-la.
No desenvolvimento de software, o uso de modelos para a descoberta e especificação das
soluções de implementação oferece, entre outras, as seguintes propriedades:
a) Precisão: os modelos descrevem, de forma precisa e correta o sistema que estão re-
presentando.
b) Compreensão: os modelos devem ser o mais simples possível, porém, de maneira
que revelem com precisão o seu propósito, e que permitam a comunicação entre os
envolvidos nos processos de desenvolvimento do software.
c) Consistência: as diferentes visões fornecidas pelos modelos devem colaborar para a
compreensão do sistema como um todo, de forma que elas permitam o esclarecimen-
to do funcionamento do sistema sob diferentes aspectos.
d) Flexibilidade: os modelos devem ser facilmente alterados, caso haja necessidade
(lembramos que essas modificações podem ocorrer por mudanças nos requisitos do
cliente ou da organização para a qual o sistema está sendo desenvolvido).
A UML é utilizada para modelar, especificar, construir ou documentar os artefatos de um
sistema. Para representar as diversas visões necessárias ao Analista, a UML é constituída de
vários elementos e diagramas (observe, na Figura 1, a estrutura dos diagramas que compõem a
UML). Algumas características atribuídas à UML:
• É independente da linguagem de programação adotada e do processo de desenvolvi-
mento de software.
• É uma linguagem de modelagem visual e expressiva, permitindo que os modelos cria-
dos pelos diferentes diagramas tenham significados.
• Por meio de mecanismos de extensibilidade e especialização, é possível ampliar os con-
ceitos, à medida que novas necessidades são descobertas.
Observe, a seguir, alguns dos tipos de sistemas informatizados nos quais a UML pode ser
utilizada:
a) Sistemas de software em geral: a UML é utilizada para modelar a infraestrutura téc-
nica que os softwares utilizam. Podem ser modelados diferentes sistemas, desde sis-
temas operacionais, até sistemas desenvolvidos especificamente para determinados
usuários, passando pelos sistemas de bancos de dados, além daqueles que executam
ações de baixo nível, ou seja, no hardware.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 85

b) Sistemas de informação: a UML é utilizada para modelar os processos de armazena-


mento, pesquisa, edição e visualização de informações para os usuários. Podem ser
modelados dados com relacionamentos complexos, que são guardados em bancos de
dados relacionais ou orientados a objetos.
c) Sistemas de tempo real integrados: são sistemas executados em simples peças de
hardware integradas a telefones celulares, carros, alarmes etc.
d) Sistemas distribuídos: são sistemas de softwares distribuídos em diferentes máquinas,
autônomas, e que compartilham não apenas os dados, mas também os recursos do
sistema.
A partir da versão 2.0, a UML é composta por treze diagramas, que são divididos em duas
categorias:
• Estruturais (ou estáticos): abstraem e enfatizam a organização do sistema.
• Comportamentais: enfatizam a dinâmica do sistema.
A seguir, uma breve apresentação destes diagramas e suas funcionalidades (maiores deta-
lhes e exemplos serão apresentados nas unidades seguintes):
a) Diagrama de Casos de Uso: mostra os atores (agentes externos ao sistema) e suas co-
nexões aos Casos de Uso fornecidos pelo sistema.
b) Diagrama de Classes: mostra a estrutura estática das classes no sistema. As classes re-
lacionam-se entre si de diferentes maneiras, ou seja, por tipos de relacionamentos di-
ferentes, tais como: dependência, associação (por agregação ou por composição), por
generalização (herança) e, ainda, agrupadas em pacotes. Estes relacionamentos são
mostrados no diagrama de classes. Além dos relacionamentos, esse diagrama mostra,
também, a estrutura interna das classes, ou seja, seus atributos e operações.
c) Diagrama de Objetos: é uma variação do diagrama de classes. A diferença está em
que o diagrama de objetos mostra um número de instâncias de objetos das classes,
e não exatamente só a classe (como ocorre no diagrama de classes). A notação para
os dois diagramas é praticamente a mesma. Normalmente, este diagrama é utilizado
com o objetivo de exemplificar diagramas de classes mais complexos, pois eles podem
mostrar as instâncias dos objetos que compõem as classes.
d) Máquina de Estados: uma máquina de estados é um complemento para a descrição
de uma classe. Cada diagrama de máquina de estado representa os estados relativos
a uma única classe. Isto é, quando ocorre mudança de comportamento nos objetos
de uma classe, o estado da classe é alterado. E, é por meio deste diagrama que os
diferentes estados para uma mesma classe podem ser representados graficamente.
Além dos estados, o diagrama mostra, também, os eventos que levam à transição de
estados (normalmente ocasionados pela troca de mensagens entre os objetos).
e) Diagrama de Atividades: mostra os fluxos principais, alternativos, de exceção e con-
correntes que compõem as atividades de um processo. Esse diagrama permite mos-
trar decisões e condições, assim como ações que são executadas paralelamente.
f) Diagramas de Sequência: mostra uma colaboração dinâmica entre objetos, exibindo visual-
mente a sequência de ações que o sistema vai executar mediante os eventos que ocorrem.
g) Diagrama de Comunicação: com o mesmo objetivo que o diagrama de sequência (mos-
trar colaboração dinâmica), este diagrama representa os aspectos comportamentais
do sistema, mostrando os objetos e os seus relacionamentos, isto é, como as intera-
ções são realizadas entre os objetos, independentemente do tempo de execução de
cada objeto. A principal diferença entre ele e o diagrama de sequência, é que o diagra-
ma de comunicação não representa o tempo como uma dimensão separada.
h) Diagrama de Componentes: um componente pode ser visto como um código-fonte,
um componente binário, ou, ainda, um componente executável. O diagrama de com-
ponentes mostra a estrutura física do código no que diz respeito aos componentes de
código. Um componente é uma parte física de um sistema, que pode ser substituída,
e que corresponde a um conjunto de interfaces. É por isso que nos sistemas, novos

Claretiano - Centro Universitário


86 © Análise e Projeto de Sistemas

componentes podem substituir outros mais antigos, se a integridade da arquitetura


do sistema for mantida. Portanto, o diagrama de componentes mostra a estrutura
física e as dependências entre os vários componentes de software.
i) Diagrama de Implantação: mostra a arquitetura física de hardware e software no sis-
tema, ou seja, a organização do hardware e a ligação do software aos dispositivos
físicos. Este diagrama revela, ainda, a dimensão do software.
j) Diagrama de Estrutura Composta: mostra como os elementos que compõem o siste-
ma (classes, interfaces e componentes) estão interconectados no momento de funcio-
namento do sistema.
k) Diagrama de Tempo: foi incorporado à UML 2.0. Seu objetivo é o de apresentar as
alterações de estado pelas quais um objeto passa ao longo do tempo de execução,
mostrando a interação entre objetos em um tempo determinado.
l) Diagrama de Interação Geral: outro diagrama que também foi incorporado à UML 2.0.
Seu objetivo é mostrar a interação entre os diagramas de sequência, comunicação e
tempo, fornecendo uma visão geral, representada por mais de um diagrama.
Veja o diagrama a seguir:
 
Diagramas UML

 
Estáticos 

Diagrama de
Diagrama de Casos de Uso
Classes

Diagrama de
Atividades
Diagrama de
Objetos

Diagrama de
Sequência

Diagrama de
Pacotes
Diagrama de
Comunicação /
Colaboração
Diagrama de
Componentes

Diagrama de
Estados /
Máquina de
Diagrama de
Estados
Composição
Estrutural /
Estrutura
Composta

Diagrama de
Integração Geral
Diagrama de
Distribuição /
Implantação /
Instalação
Diagrama de
Tempo /
Diagrama de
Sincronismo

Diagramas novos ou que sofreram


Diagramas novos ou que sofreram alteração
alteração para
paraa UML
a UML2.0 2.0

Figura 1 Estrutura dos diagramas da UML.


© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 87

Fazendo uma retrospectiva do ciclo de desenvolvimento de um sistema de software, de-


vemos nos lembrar que duas das etapas deste ciclo são a Análise e o Projeto do sistema. A fase
da Análise enfatiza a investigação do problema, enquanto na fase de Projeto, a ênfase está na
proposta de uma solução que atenda aos requisitos da análise. O projeto propõe uma solução
com base nos levantamentos e conhecimentos obtidos na fase da análise.
Nestas duas fases do desenvolvimento de um software é que a UML se fará presente, pois
é nelas que os diagramas da UML serão elaborados. Ou seja, sempre que você estiver desen-
volvendo um software orientado a objetos, fará uso da UML para desenhar os diagramas que
vão modelar o software. Cada diagrama tem uma função específica e representa uma visão que
se tem do sistema. Observe que nem todo sistema necessita de todos os diagramas para sua
modelagem estar completa. Entretanto, alguns deles são imprescindíveis para a criação dos mo-
delos que representarão o sistema a ser desenvolvido.
No decorrer desta e das próximas unidades, os diagramas serão apresentados, e você terá
a oportunidade de ver exemplos dos principais e mais utilizados.

6. CONCEPÇÃO DO SISTEMA
A concepção é uma fase do desenvolvimento de sistema em que o analista busca as infor-
mações iniciais sobre o novo sistema. Não podemos nos esquecer que, normalmente, as pes-
soas que fazem parte da equipe de desenvolvimento não têm conhecimento sobre os assuntos
relacionados aos processos de negócio da empresa para a qual vão desenvolver o software.
Por outro lado, o cliente e usuários do novo sistema também não possuem conhecimen-
tos na área de informática. Por isso, é importante lembrar que esta situação exige uma grande
interação do desenvolvedor com cliente e usuários.
Por isso, há várias metodologias que podem ser adotadas no desenvolvimento de um sis-
tema. Dentre elas, uma das mais utilizadas é a do desenvolvimento iterativo, em que o sistema
é dividido em processos menores.
No desenvolvimento iterativo, as fases de especificação (análise), projeto, desenvolvimen-
to e teste são intercaladas em vários ciclos. A cada ciclo, novos requisitos podem ser incorpora-
dos ao sistema.
A primeira etapa geral de desenvolvimento é a especificação do software, que abrange
um estágio conhecido como concepção do sistema. A fase de concepção pode ser dividida em
levantamento de requisitos, organização dos requisitos e planejamento do desenvolvimento.
Ela refere-se ao contato inicial do desenvolvedor com o cliente, com o objetivo de buscar infor-
mações que permitam descobrir e definir o problema do cliente, ou seja, o que ele espera do
sistema.
Trata-se de uma tarefa rápida, pois esta busca deverá ser superficial, apenas para se ter
uma ideia geral sobre o sistema. É uma etapa que permite ao desenvolvedor chegar a uma con-
clusão, ou seja, se deve continuar ou não com o projeto. Chamamos esta etapa de estudo da
viabilidade do sistema.
Na fase de concepção cabe, também, uma estimativa de custo, pois um dos documentos
gerados nesta fase é um contrato de desenvolvimento do sistema. Este contrato deve incluir,
entre outros detalhes, o custo do projeto e um cronograma.

Claretiano - Centro Universitário


88 © Análise e Projeto de Sistemas

Cada fase do ciclo de desenvolvimento de um sistema produz alguns artefatos. Entretanto,


nesta fase, os artefatos ainda são documentos desestruturados.

Levantamento de requisitos
Realizar o levantamento de requisitos significa buscar todas as informações possíveis sobre
aquilo que se espera do sistema. Essas informações são fornecidas pelos usuários, mas podem
também ser obtidas na análise de documentos, em outros sistemas, e até mesmo observando a
interação dos usuários com o sistema atual.
A fase da concepção fornece uma visão geral do sistema a ser construído, ou seja, o sufi-
ciente para se saber o que é mais importante. Apenas em uma fase posterior é que o sistema
será dividido em partes e os detalhes serão analisados.
É por isso que se diz que a fase da concepção deve ser executada em extensão, e não em
profundidade. Inicialmente, deve-se apenas compreender a extensão do problema. Os detalhes
serão resolvidos posteriormente, quando o sistema for dividido e solucionado em ciclos iterati-
vos, por meio de uma análise aprofundada do mesmo.
Normalmente, os requisitos podem ser divididos em funcionais e não funcionais. Os re-
quisitos funcionais são aqueles relacionados aos serviços que o sistema deve fornecer. Os não
funcionais referem-se às restrições sobre as funções e as operações que o sistema deve fornecer
ou realizar.
Para Wazlawick (2004), além da classificação dos requisitos nas categorias de funcionais e
não funcionais, podemos ter a classificação descrita no Quadro 1.
Quadro 1 Classificação de Requisitos.
TIPOS DE REQUISITOS CLASSIFICAÇÃO
Funcionais Evidentes/Ocultos
Obrigatórios/Desejáveis
Não funcionais Permanente/Transitórios
Categorias
Obrigatórios/Desejáveis
Suplementares Permanente/Transitórios
Categorias

Analisando o quadro anterior, é possível apreender que um requisito funcional é evidente


quando o usuário tem conhecimento sobre ele. Caso contrário, ele é um requisito oculto.
Um requisito não funcional ou um requisito suplementar pode ser obrigatório quando
for obtido de qualquer maneira, isto é, quando ele é essencial ao sistema. Caso contrário, é
desejável. Pode ser, ainda, permanente, quando se sabe que ele nunca mudará com o tempo,
ou transitório.
A categoria refere-se ao tipo de restrição. Pode ser de usabilidade, performance, confiabi-
lidade, segurança ou interface, entre outros.
É comum que um requisito não funcional esteja diretamente relacionado a um requisito
funcional. Entretanto, os requisitos não funcionais podem não ter ligações diretas com qualquer
outro funcional. Nesse caso, eles são chamados de suplementares.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 89

Ao descobrirmos os requisitos de um sistema, é necessário que eles sejam especificados,


ou seja, declarados. Assim, é gerado um artefato conhecido como documento de especificação
dos requisitos do sistema.
Outro artefato importante, criado durante todo o desenvolvimento do sistema, é o glos-
sário. Ele é um documento utilizado para definir e padronizar os termos técnicos do domínio da
aplicação.

7. CASOS DE USO
Segundo Larman (2000, p. 68), "Caso de Uso é um documento narrativo que descreve
a sequência de eventos de um ator (agente externo) que usa um sistema para completar um
processo".
Podemos dizer que eles representam um conjunto de ações executadas por um sistema,
relacionadas a um ator. É importante destacar que eles não revelam a estrutura e o comporta-
mento interno do sistema, mas sim a interação entre um ator e o sistema, em que são mostra-
das as funcionalidades disponibilizadas por esse sistema.
Os principais objetivos para a criação de Casos de Uso são:
• Encontrar e descrever os requisitos funcionais do sistema, como forma de mostrar que
desenvolvedores e clientes estão de acordo sobre o que será desenvolvido.
• Fornecer uma visão clara e consistente sobre o que o sistema deve fazer.
• Fornecer uma base para a execução de testes que verifiquem se o sistema trabalha
apropriadamente, validando-o.
Veja que há várias formas para descrever Casos de Uso, tais como: um texto contínuo, uma
sequência numerada ou a utilização de tabelas.
Vamos utilizar como exemplo uma livraria em que o usuário possa pesquisar em um ter-
minal disponível informações sobre determinado produto que deseja. No formato de texto con-
tínuo, o Caso de Uso pode ser descrito da seguinte forma:

Descrição de Caso de Uso: texto contínuo


O cliente chega à livraria. No terminal de consulta, o sistema mostra as formas de pesquisa
(por título da obra, pelo nome do autor, pelo nome da editora). O cliente escolhe a forma de
pesquisa que lhe interessa. O sistema exibe as informações sobre o produto desejado.
O mesmo Caso de Uso pode ser descrito sob a forma de uma sequência numerada das
ações que ocorrem entre ator e sistema. Veja a seguir.

Descrição de Caso de Uso: sequência numerada


1) Cliente chega à livraria e dirige-se a um terminal de consulta.
2) O sistema exibe as formas de pesquisa (por título da obra, pelo nome do autor, pelo
nome da editora).
3) O cliente escolhe a forma de pesquisa que lhe interessa.
4) O sistema exibe as informações sobre o produto desejado.
E, ainda, o Caso de Uso pode ser descrito no formato tabular, observe a tabela a seguir.

Claretiano - Centro Universitário


90 © Análise e Projeto de Sistemas

Descrição de Caso de Uso: tabela


CLIENTE SISTEMA
1. Cliente chega à livraria e dirige-se a um terminal de 2. Sistema exibe as formas de pesquisa (por título da obra, pelo
consulta. nome do autor, pelo nome da editora).
3. Cliente escolhe a forma de pesquisa que lhe interessa. 4. Sistema exibe as informações sobre o produto desejado.

O Caso de Uso livraria mostra apenas um cenário, no qual descreve as ações da forma
como se espera que elas aconteçam, isto é, atingindo o objetivo esperado. No exemplo dado,
espera-se que o resultado final seja a exibição das informações sobre o produto pesquisado.
Quando descrevemos um Caso de Uso, nem sempre as ações terminarão com êxito. Isso
pode ocorrer por diversos motivos, e o Caso de Uso deve mostrar os cenários que não levam ao
objetivo esperado. Esses cenários descrevem operações que compõem os chamados fluxos de
exceção.
É por meio dos Casos de Uso que se mapeiam as exigências funcionais do sistema. O pro-
cesso de criação de um Caso de Uso é um processo iterativo porque, à medida que adquirimos
maior compreensão do sistema, isolamos e modelamos outras partes do problema, de forma
que os Casos de Uso vão sendo modificados, visto que eles, naturalmente, deverão representar
informações sobre o seu relacionamento com outros Casos de Uso. Gradualmente, construímos
a visão de um sistema cada vez mais completo.
Resumindo, podemos afirmar que os objetivos de um Caso de Uso São:
a) Decidir e descrever os requisitos funcionais do sistema;
b) Prover uma descrição clara e consistente do que o sistema deve fazer;
c) Prover a base para a realização de testes que validam e verificam o sistema;
d) Prover facilidades para rastrear requisitos funcionais dentro das classes e operações
do sistema.
Observe, a seguir, algumas dicas para a identificação de Casos de Uso:
a) Quais são as funções que o ator necessita do sistema?
b) O que o ator necessita fazer?
c) O ator precisa armazenar, consultar, excluir ou alterar algum tipo de informação no
sistema?
d) Quais são os principais problemas com a implementação atual do sistema?
Agora, começaremos o desenvolvimento de um Software Educacional. Essa atividade con-
tinuará nas próximas unidades para efeito de exemplificação dos conceitos e diagramas estuda-
dos em cada uma delas.

Um projeto para especificação de Casos de Uso: uma proposta de Software Educacional


Para melhor exemplificar os diagramas, apresentaremos uma proposta de Software Edu-
cacional.
Desenvolver um Software Educacional tem como objetivo auxiliar no processo de avalia-
ção de conteúdos ensinados pelo professor, oferecendo funcionalidades de montagem e apli-
cação de avaliações com questões de múltipla escolha, disponibilizando, também, a correção
automática da avaliação para o professor e para os alunos, bem como a geração de relatórios de
desempenho de alunos. Além disso, o Software Educacional controla o acesso aos usuários por
questões de segurança.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 91

Com base nas entrevistas realizadas com os professores, foi elaborado um protótipo das
telas do software e os seguintes módulos foram identificados:
Quadro 2 Protótipo das telas do software.
MÓDULOS IDENTIFICADOS NOS PROTÓTIPOS DAS TELAS DO SOFTWARE
Tem como função apoiar o gerenciamento dos usuários do sistema, por meio do cadastramento de
Administrador
professores e de alunos.
Tem como função apoiar o gerenciamento da aplicação de avaliações aos alunos, a partir do
cadastramento de um banco de questões, do cadastramento de avaliações, da liberação das
Professor
avaliações para os alunos, da correção automatizada das avaliações e, finalmente, da geração de
relatório de desempenho dos alunos por avaliação.
Tem como função apoiar a aplicação das avaliações aos alunos, por meio da liberação da avaliação e,
Aluno
também, da liberação dos resultados para ele.

Nome do Caso de Uso


O primeiro elemento da estrutura de um Caso de Uso é o seu identificador, ou seja, seu
nome, já que todo Caso de Uso deve possuir um nome que o diferencie dos demais. Para no-
meá-lo, iniciamos o Caso de Uso com um verbo no infinitivo.
Por exemplo:
• Manter dados de questões de múltipla escolha.
• Manter dados de avaliações.
• Liberar avaliações etc.
Graficamente, o Caso de Uso é representado por uma elipse com o seu nome no interior
ou abaixo dele, opcionalmente, como mostra a figura a seguir:

Figura 2 Representação gráfica de um Caso de Uso.

A seguir, listamos os Casos de Uso identificados no sistema:


a) Efetuar logon no sistema.
b) Manter dados de usuários (inserir, alterar, excluir, listar usuários).
c) Manter dados de questões de múltipla escolha (inserir, alterar, excluir, listar ques-
tões).
d) Manter dados de avaliações (inserir, alterar, excluir, listar avaliações).
e) Liberar avaliações para os alunos.
f) Bloquear avaliações para os alunos.
g) Liberar respostas para os alunos.
h) Consultar avaliação de aluno.
i) Listar relatório de desempenho de avaliações por alunos.
j) Listar relatório de desempenho de avaliações por avaliação.

Claretiano - Centro Universitário


92 © Análise e Projeto de Sistemas

Acompanhe, a seguir, uma breve descrição para que você possa compreender melhor o
sistema apresentado.

Descrição
Para facilitar sua compreensão e das pessoas que irão trabalhar no projeto do software,
no futuro, você deverá compreender melhor o sistema para poder modificá-lo. Para tanto, do-
cumentamos o objetivo do Caso de Uso.
Por exemplo:
Caso de Uso – inserir dados de usuários: este Caso de Uso permite ao administrador ca-
dastrar os dados dos usuários do sistema.
Pré-condições
É possível que um determinado Caso de Uso tenha de obedecer a algum tipo de restrição
ou pré-requisito para que seja executado. Nesse caso, devemos registrar algumas informações
e acompanhá-las atentamente

Atores envolvidos
A melhor maneira para iniciar o estudo dos Casos de Uso é por quem interage com o sis-
tema, ou seja, os atores envolvidos.
Um Caso de Uso descreve um conjunto de atividades a serem realizadas. Todavia, é sempre
iniciado por um estímulo, o qual é causado por um ator. Em um sistema, é comum encontrarmos
vários atores envolvidos. Eles podem ser pessoas ou qualquer outro objeto, como, por exemplo,
uma impressora ou um carro, inclusive outros sistemas de software interagindo com ele.
Portanto, o ator não é sinônimo de pessoa. A comunicação entre os atores e o sistema é
feita por meio dos Casos de Uso, que representam uma sequência de ações executadas pelo
sistema.
Observe, a seguir, como um ator pode interagir com um Caso de Uso:
a) Ativar ou chamar um Caso de Uso. Nesse caso, uma instância do Caso de Uso será
criada.
b) Solicitar dados no sistema por meio do Caso de Uso.
c) Modificar os dados armazenados.
d) Informar algum evento externo ao sistema.

Figura 3 Representação de um ator.


© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 93

Os atores representam o papel de uma entidade externa ao sistema. Vale ressaltar que
um ator não representa necessariamente uma entidade física específica, mas um papel, um as-
pecto particular de alguma entidade. Por exemplo, Paulo é um professor que utilizará o sistema.
Apenas o papel dele será abstraído, portanto, ele será representado como um ator Professor.
Joel é um aluno que vai utilizar o sistema. Apenas o papel dele será abstraído, portanto, ele será
representado como um ator Aluno. O terceiro papel abstraído do sistema é o de Administrador,
que é a pessoa responsável por cadastrar quem utilizará o sistema.
Assim como ocorre com as classes, os atores podem ser generalizados. Isso ocorre porque
os atores de um sistema são abstraídos como classes. Por exemplo, foi solicitado o controle de
acesso, por meio de login e senha a todos os que utilizarem o sistema. Percebe-se, com isso, a
necessidade de abstrair os atores Aluno, Professor e Administrador em um ator mais genérico,
o ator Usuário (opcionalmente, também poderia ser referido como pessoa, mas optou-se por
usuário, por ser um termo mais adequado ao âmbito da análise de sistemas).
A generalização acontece visto que os atores Aluno, Professor e Administrador executarão
o mesmo método para se registrarem no sistema com login e senha.
A Figura 4 representa o Diagrama de Atores do sistema.

Figura 4 Representação do Diagrama de Atores do sistema com generalização/especialização.

O principal caminho para você entender o funcionamento de um sistema qualquer, é des-


cobrir como Casos de Uso e atores interagem enviando sinais uns aos outros. Para compreender
o papel do ator, é necessário saber com quais Casos de Uso ele está interagindo, sendo esta uma
função das associações: identificar os Casos de Uso e seus atores.
Observe o questionário a seguir. A partir dele, algumas pistas para identificar os atores
podem surgir.
a) Quem são os principais utilizadores do sistema?
b) Quem irá administrar e fazer com que o sistema permaneça operando?
c) Quem proverá suporte ao sistema em seu processamento diário?
d) Quem ou o que utiliza os resultados que o sistema produz?
e) Quais dispositivos de hardware são necessários ao sistema?
f) Com quais outros sistemas o sistema em questão interagirá?

Claretiano - Centro Universitário


94 © Análise e Projeto de Sistemas

Veja, a seguir, a representação gráfica dessa associação.

Figura 5 Representação gráfica de um Caso de Uso completo.

Figura 6 Representação gráfica do Caso de Uso Efetuar Logon.

Cenário principal (fluxo de eventos principais)


Ao interagir com um Caso de Uso, um ator pode atuar em um cenário principal, no qual
tudo ocorre linearmente, em um caminho específico de execução por meio do sistema, ou em
possíveis cenários alternativos, nos quais são tratados os erros e exceções em resposta às inte-
rações dos usuários.
Basicamente, um cenário é a descrição dos eventos que devem acontecer quando o Caso
de Uso é executado ou recebe um estímulo. Por se tratar de um fluxo de acontecimentos, suge-
re-se que o cenário principal seja descrito em termos de passos a serem seguidos, os quais, por
sua vez, podem ser estruturados em tópicos, para melhor compreender o cenário.

Cenário alternativo (fluxos de exceção)


No cenário alternativo, como já foi dito, são tratados os erros e as exceções em resposta
às interações dos usuários.

Requisitos especiais
Neste tópico, documentamos opcionalmente quaisquer situações não contempladas an-
teriormente.

Dados
Documentamos, opcionalmente, os tipos de dados que foram encontrados durante a des-
crição do Caso de Uso, no qual informamos: texto, número, data etc.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 95

Exemplos de especificações de Caso de Uso


Vamos, agora, estudar dois exemplos de especificações de Casos de Uso para fixação dos
conceitos. Começaremos com o Caso de Uso "Efetuar logon".
I) Ator relacionado
Administrador, Professor e Aluno, todos chamados de usuários para facilitar a especifica-
ção deste Caso de Uso.
II) Objetivo
Permitir aos usuários registrar entrada no sistema e, com base nisso, escolher as opções
disponíveis para cada tipo de usuário.
III) Fluxo de eventos principais
Para realizar o fluxo de eventos principais, observe atentamente os passos que o sistema
deverá verificar.
Passo 1: inicialmente, o sistema apresenta a tela de logon ao usuário, como demonstra a
Figura 7, a seguir.

Figura 7 Protótipo da tela de Logon do sistema.

Passo 2: o usuário informa seu login e senha.


Passo 3: o sistema verifica se este usuário (Login) está cadastrado (E1).
Passo 4: o sistema verifica se a senha para este usuário está correta (E2).
Passo 5: o sistema verifica se o usuário não está logado no sistema (E3).
Passo 6: o sistema registra o usuário, gravando, também, a hora de entrada dele.
Passo 7: o sistema apresenta a tela principal com as opções habilitadas para cada tipo de
usuário que efetuar Logon.
a) Se o usuário é do tipo Administrador, o sistema habilita as opções:
1) Manter dados de Usuários (inserir, alterar, excluir, listar usuários).
2) Sair.
b) Se o usuário é do tipo Professor, o sistema habilita as opções:
1) Manter dados de Questões de Múltipla Escolha (inserir, alterar, excluir, listar questões).
2) Manter dados de Avaliações – Questões de Múltipla Escolha (inserir, alterar, ex-
cluir, listar avaliações).

Claretiano - Centro Universitário


96 © Análise e Projeto de Sistemas

3) Liberar avaliações para os alunos.


4) Bloquear avaliações para os alunos.
5) Listar relatório de desempenho de avaliações por alunos.
6) Listar relatório de desempenho de avaliações por avaliação.
7) Consultar avaliação de aluno.
8) Sair.
c) Se o usuário é do tipo Aluno, o sistema habilita as opções:
1) Resolver avaliações.
2) Listar relatório de desempenho de avaliações por avaliação.
3) Consultar avaliação.
4) Sair.
d) Se os usuários (Administrador/Professor/Aluno) escolherem "Sair", o sistema volta ao
início, ou seja, ao Passo 1; senão o sistema irá para o Caso de Uso correspondente à
escolha do usuário.
IV) Fluxos de Exceção
• Exceção 1: se o login do usuário não estiver cadastrado, o sistema apresenta a mensa-
gem de erro: "login não cadastrado, tente novamente". Explica o problema e volta ao
Passo 1.
• Exceção 2: se a senha não estiver correta, o sistema apresenta uma mensagem de erro:
"login ou Senha inválidos, tente novamente". Após explicar o problema, retorna ao
Passo 1.
• Exceção 3: se o usuário já estiver logado, o sistema apresenta a seguinte mensagem de
erro: "Usuário já se encontra logado no sistema" e, a seguir, volta ao Passo 7.
Vejamos, agora, o segundo exemplo: Manter Dados de Usuários. Especificação de Caso de
Uso "Menu Principal do Administrador".
I) Ator relacionado
Administrador.
II) Objetivo
Permitir ao Administrador acessar as funções de manutenção dos dados dos usuários do
sistema.
III) Fluxo de Eventos Principal
Passo 1: o sistema apresenta a tela de Manutenção de dados de usuários ao Administrador
(conforme demonstra a Figura 8). Serão apresentadas as opções: "Inserir", "Alterar", "Excluir",
"Consultar" e "Menu principal".
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 97

Figura 8 Protótipo da tela principal do Administrador.

a) Se o Administrador escolher a opção "Inserir", o sistema apresenta a tela de Cadastro


de Usuários. Serão apresentados os campos de preenchimento, as instruções para o
preenchimento e as opções "Inserir", e "Menu principal".
b) Se o Administrador escolher a opção "Alterar", o sistema apresenta a tela de pesquisa
de usuários para alteração de cadastro. Serão apresentados os campos de busca e a
opção "Menu principal", e se o usuário escolher a opção "Menu Principal", o sistema
volta à tela inicial do Administrador do sistema.
c) Se o usuário escolher a opção "Excluir", o sistema apresenta a tela de pesquisa de
usuários para exclusão de cadastro. Serão apresentados os campos de busca e a opção
"Menu principal", se o usuário escolher a opção "Menu Principal", o sistema volta à
tela inicial do Administrador do sistema.
d) Se o Administrador escolher a opção "Consultar", o sistema apresenta a tela de pes-
quisa de usuários para alteração de cadastro. Serão apresentados os campos de busca
e a opção "Menu principal", e se o usuário escolher a opção "Menu Principal", o siste-
ma volta à tela inicial do Administrador do sistema.
e) Se o Administrador escolher a opção "Menu principal", o sistema volta à tela principal
do Administrador do sistema.
IV) Fluxo de Exceção
O Menu Principal do Administrador não possui fluxos de exceção.
Vamos, agora, estudar um Caso de Uso da função Inserir Dados de Usuários.
I) Ator relacionado
Administrador.
II) Objetivo
Permitir ao Administrador inserir dados de novos usuários do sistema.

III) Fluxo de Eventos Principal


Passo 1: o sistema apresenta a tela de Cadastro de Usuários ao Administrador (conforme
demonstra a Figura 9).

Claretiano - Centro Universitário


98 © Análise e Projeto de Sistemas

Sistema Gerenciador de Avaliações de


Questões de Múltipla Escola
Cadastro de Usuários
Nome

e-mail Salvar

Login Menu Principal

Senha

Confirmação da Senha

Tipo de Usuário

Atenção:
1) Todos os campos devem ser preenchidos obrigatoriamente
2) A senha deve conter 6 dígitos, que podem ser letras e/ou números
Figura 9 Protótipo da tela de cadastro de novos usuários.

Passo 2: o Administrador informa os dados ao sistema. Campos: nome, e-mail, login, se-
nha, confirmação da senha, tipo de usuário (professor ou aluno). Todos os campos são obriga-
tórios.
Passo 3: o Administrador escolhe a opção "Salvar".
a) O sistema verifica se os campos obrigatórios foram preenchidos (Exceção 1).
Atente ao fato de que, no final de alguns itens, há uma frase entre parênteses descrita
"(Exceção n.)" na qual o número apresentado contém uma exceção descrita no tópico
a seguir "Fluxo de Exceção".
b) A senha pode conter apenas seis dígitos, que podem ser números e/ou letras (Exceção
2).
c) A senha não pode ser a mesma que o login (Exceção 3).
d) O login não pode ser o mesmo que algum outro já cadastrado anteriormente (Exceção
4).
e) O sistema envia mensagem "Confirmar inclusão de novo usuário?" para o Administra-
dor confirmar a inserção do novo Usuário.
f) O Administrador confirma a inclusão do novo usuário (Exceção 5).
g) O sistema apresenta a tela do Menu Principal ao Administrador.
IV) Fluxo de Exceção
• Exceção 1: se algum campo obrigatório não estiver preenchido, o sistema apresenta
uma mensagem de erro: "Verifique o preenchimento dos campos obrigatórios". Explica
o problema, mantendo na tela os dados que já foram preenchidos.
• Exceção 2: se a senha não contiver seis dígitos, o sistema apresenta a seguinte men-
sagem de erro: "Senha inválida – deve conter obrigatoriamente seis dígitos". Explica o
problema, mantendo os dados que já foram preenchidos e deixando os campos: "Se-
nha" e "Confirmação" não preenchidas.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 99

• Exceção 3: se a confirmação da senha não coincidir com a senha informada, o sistema


apresenta a mensagem de erro: "A confirmação de senha deve coincidir com a senha
informada". Explica o problema, mantendo os dados que já foram preenchidos e dei-
xando os campos: "Senha" e "Confirmação" não preenchidas.
• Exceção 4: se o Login coincidir com algum outro cadastrado anterior, o sistema apre-
senta uma mensagem de erro: "Login já utilizado por outro usuário – escolha outro".
Explica o problema, mantendo os dados que foram preenchidos e deixando os campos
"Login", "Senha" e "Confirmação", não preenchidas.
• Exceção 5: se o Administrador não confirmar a inclusão do novo usuário, o sistema can-
cela a operação e apresenta a tela do Menu Principal ao Administrador.
Vamos estudar, agora, um Caso de Uso da função Consultar Dados de Usuários.
I) Ator relacionado
Administrador.
II) Objetivo
Permitir ao Administrador consultar dados de novos usuários do sistema.
III) Fluxo de Eventos Principal
Passo 1: o sistema apresenta a tela de Consulta de Usuários ao Administrador (conforme
demonstra a Figura 10).

Figura 10 Protótipo da tela de busca para consulta ao cadastro de usuários.

Passo 2: o administrador informa o nome ou parte do nome do usuário que deverá ter
seus dados alterados, este campo, no entanto, não é obrigatório, e seleciona a opção "buscar".
O sistema listará todos os usuários cadastrados caso não seja informado um nome ou parte de
um nome (Exceção 1).
Passo 3: o administrador seleciona um nome na lista de usuários apresentada pelo sistema.
Passo 4: o sistema apresenta a tela com os dados do usuário selecionado.

Claretiano - Centro Universitário


100 © Análise e Projeto de Sistemas

IV) Fluxo de Exceção


Exceção: se nenhum usuário foi localizado, o sistema apresenta uma mensagem: "Nenhum
usuário encontrado".
Apresentamos, até o momento, a estrutura mínima para a especificação de um Caso de
Uso. Entretanto, é possível adicionar mais dados. Medeiros (2004, p. 39), por exemplo, propõe
a seguinte estrutura para um Caso de Uso:
a) Nome do Caso de Uso;
b) Breve descrição;
c) Pré-condições;
d) Atores envolvidos;
e) Cenário principal;
f) Cenário alternativo;
g) Requisitos especiais;
h) Dados.

8. APROFUNDANDO CASOS DE USO: INCLUSÃO, EXTENSÃO E GENERALIZAÇÃO


Como vimos anteriormente, a modelagem é um processo iterativo, ou seja, voltamos a
ele várias vezes, a fim de torná-lo cada vez mais completo. Ao modelar Casos de Uso, individu-
almente, você perceberá que muitos deles não são processos isolados do sistema, mas que, em
algum momento, eles podem interagir com outros Casos de Uso.
Portanto, para melhor representar estes relacionamentos, a UML disponibiliza três tipos
de Casos de Uso:
• Inclusão.
• Extensão.
• Generalização.

Inclusão
Inclusão é um tipo de relacionamento utilizado para representar o cenário comum a mais
que um Caso de Uso. Além disso, representa-se o processo em um Caso de Uso base, para que
outros Casos de Uso possam utilizá-lo.
O principal objetivo deste relacionamento é eliminar a redundância de informações, isso
evita a descrição da mesma sequência de passos em vários Casos de Uso, concentrando-a em
um Caso de Uso específico. A representação gráfica é dada por meio do estereótipo de inclusão
da seguinte maneira:
<<include>>
No exemplo a seguir, o processo de escolha de destinatário é comum nos dois Casos de
Uso e isolado no Caso de Uso "Escolher Destinatário".
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 101

Figura 11 Exemplo de Caso de Uso com relacionamento de inclusão.

Extensão
O relacionamento de extensão é utilizado para descrever cenários que ocorrerão em uma
situação específica, ou, ainda, cenários opcionais de um Caso de Uso. A representação é dada
pelo seguinte estereótipo:
<<extend>>
Vale ressaltar que o Caso de Uso modelado não controla as condições para a execução
do Caso de Uso estendido, pois este último pode acessar e modificar atributos do Caso de Uso
básico, mas este (o básico) não pode ver as extensões nem acessar seus atributos.
No próximo exemplo, o Caso de Uso "Criptografar Mensagem" é cenário específico para o
Caso de Uso de "Enviar Mensagem".

Figura 12 Exemplo de Caso de Uso com relacionamento de extensão.

Generalização
A generalização é um relacionamento entre Casos de Uso no qual toda estrutura do Caso
de Uso "generalizado" é herdada pelos Casos de Uso "especializados". Os subtipos, ou seja, os
Casos de Uso "especializados", por sua vez, podem conter cenários específicos para cada um
deles. Observe a Figura 13:

Claretiano - Centro Universitário


102 © Análise e Projeto de Sistemas

Figura 13 Representação de generalização/especialização de um Caso de Uso.

Pacotes de Casos de Uso


Conforme a evolução do levantamento e da análise de requisitos, surgem muitos Casos
de Uso. Juntá-los em um único diagrama pode dificultar o entendimento e o gerenciamento do
projeto. Para tanto, utilizamos, então, um Pacote de Caso de Uso. Este pacote é uma coleção
de Casos de Uso, atores, relacionamentos, diagramas e até mesmo de outros pacotes, o qual é
utilizado para estruturar o modelo de Casos de Uso, dividindo-o em pares menores, mais fáceis
de entender.
Um Pacote de Caso de Uso contém as seguintes propriedades:
a) Nome do pacote: deve ser único e descrever as responsabilidades dos elementos que
ele contém.
b) Breve descrição do papel e do propósito do pacote.
c) Casos de Uso contidos diretamente no pacote.
d) Atores associados aos Casos de Uso do pacote.
e) Relacionamentos entre os Casos de Uso e outros pacotes.
f) Diagramas referentes aos Casos de Uso do pacote.
g) Pacotes eventualmente contidos em pacotes de mais alto nível.
Vamos utilizar como exemplo um Pacote de Casos de Uso do Sistema Gerenciador de Ava-
liações de Questões de Múltipla Escolha.
Partindo do ponto de vista de cada ator do sistema, levantamos anteriormente uma lista
de Casos de Uso e sabemos, também, quais atores se relacionam com esses Casos de Uso. Por-
tanto, veja como ficará fácil organizar o sistema em pacotes.
Para tanto, observe, no quadro, a seguir a organização dos Casos de Uso levando em con-
sideração a abstração da modularização.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 103

Quadro 3 Organização dos Casos de Uso levando em consideração a abstração da modularização.


ATOR PROCESSO
Usuários • Efetuar logon no sistema.
Administrador • Manter dados dos usuários (inserir, alterar, excluir e listar usuários).
• Manter dados de Questões de Múltipla Escolha (inserir, alterar, excluir e listar questões).
• Manter dados de Avaliações com Questões de Múltipla Escolha (inserir, alterar, excluir e listar
avaliações).
• Liberar avaliações para os alunos.
Professor
• Bloquear avaliações para os alunos.
• Listar relatório de desempenho de avaliações por alunos.
• Listar relatório de desempenho de avaliações por avaliação.
• Consultar avaliação de aluno.
• Resolver avaliações.
Aluno • Listar relatório de desempenho de avaliações por avaliação.
• Consultar avaliação.

Representamos, na Figura 14, o Diagrama de Pacotes do Sistema Gerenciador de Ava-


liações. Nele, um pacote pode ou não revelar seu conteúdo, todavia, comumente um pacote
mostra seus subpacotes em seu interior.
Neste diagrama, também podemos representar os atores envolvidos em cada grupo de
pacotes, bem como o relacionamento entre os grupos de pacotes.
Observe, a seguir, o Diagrama de Pacotes:

Figura 14 Diagrama de Pacotes do Sistema Gerenciador de Avaliações.

Claretiano - Centro Universitário


104 © Análise e Projeto de Sistemas

9. DIAGRAMA DE CASOS DE USO


Um sistema é formado por diversos Casos de Uso, cada um é responsável por descrever
uma funcionalidade do sistema. Assim, o conjunto de todos os Casos de Uso mostra a funcionali-
dade do sistema como um todo. Devemos ressaltar que a modelagem de Casos de Uso pode ser
vista como uma "caixa-preta", ou seja, não importa como os Casos de Uso são implementados,
nem como eles trabalham internamente. Isso significa que, embora cada Caso de Uso descreva
uma funcionalidade do sistema, nada se sabe sobre "como" isso seja feito.
Para representar todos os Casos de Uso de um sistema, a UML possui uma notação gráfica
chamada diagrama de Casos de Uso. Por meio dele é possível visualizar, em um alto nível de
abstração, quais os elementos (atores ou agentes externos) que interagem com o sistema em
cada funcionalidade, descritas nos Casos de Uso. Portanto, os diagramas de Casos de Uso repre-
sentam, visualmente, o conjunto de atores, os Casos de Uso e as relações entre eles. .
Tomando como exemplo o Sistema Livraria, se considerarmos apenas um Caso de Uso
(Pesquisar Livro), o diagrama de Casos de Uso fica conforme descrito na figura a seguir.

Figura 15 Parte do diagrama de Casos de Uso – Sistema Livraria.

Para melhor visualização e compreensão do assunto estudado nesta unidade veremos, a


seguir, um exemplo de parte de um sistema para uma livraria, o qual, discutiremos também, nas
próximas unidades.
Lembre-se de que estamos estudando o Software Educacional. Observe como podemos
desenvolver sistemas com algumas particularidades. Por exemplo, foram apresentadas três ma-
neiras diferentes de escrever os Casos de Uso. Cada um dos nossos sistemas de exemplo trata
isso de uma forma diferente. Cabe a você decidir qual irá utilizar posteriormente.

10. EXEMPLO: SISTEMA LIVRARIA


Antes de iniciar o exemplo, realizaremos uma rápida revisão do conteúdo. Você está lem-
brado que para desenvolver um sistema de software é necessário, inicialmente, fazer um traba-
lho de levantamento de informações sobre o sistema desejado pelo cliente. Esta fase é denomi-
nada levantamento de requisitos, e dela originará o primeiro artefato de produção do sistema,
denominado documento de especificação de software.
Portanto, começaremos nosso sistema por sua especificação. A especificação do sistema
é uma declaração, escrita neste contexto em linguagem natural, para descrever o que o cliente
deseja do sistema, ou o que se espera que o sistema faça.

Especificação do sistema
Trata-se de um sistema para controlar as vendas de livros de uma livraria. Vale destacar
que um sistema responsável por gerenciar os processos de negócios de uma livraria é muito
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 105

maior que o que vamos descrever, pois ele deve contemplar vários aspectos que, no momento,
não abordaremos. Neste exemplo, nossa preocupação é demonstrar apenas os aspectos rela-
cionados à venda dos livros.
Para o bom funcionamento deste sistema, a loja deverá ter terminais de consultas espa-
lhados em alguns pontos, para que o cliente possa fazer sua pesquisa. Esta pesquisa tem como
objetivo buscar informações relacionadas ao livro desejado, tais como: preço, disponibilidade
para venda, informações sobre a obra, autor, editora, entre outras.
O cliente pode pesquisar pelo título da obra, nome do autor ou nome da editora. Ao re-
ceber a informação desejada, ele deverá se dirigir ao vendedor, que se encarregará de iniciar
o processo de compra do livro. Caso a loja não possua exemplares para a venda, mas tenha a
disponibilidade para pedidos, o cliente pode solicitar ao vendedor que faça o pedido do livro.
Para encomendar, basta o cliente fornecer seu nome e telefone.
Quando o livro chegar à livraria, o cliente é avisado para que o processo de venda seja
efetivado. Outra possibilidade é a de o cliente deixar o pedido pago, de modo que, quando o
livro chegar à livraria, ele imediatamente é despachado. Toda operação de entrada ou saída de
um livro gera uma movimentação de atualização do estoque da livraria. O sistema permite que,
nos casos de encomenda de livros, o vendedor possa acompanhar o status dos pedidos de seus
clientes.
Quanto à forma de pagamento, o cliente pode optar pelo pagamento à vista (em dinheiro
ou cartão de débito), com cartão de crédito ou, ainda, com boleto bancário, se o valor da venda
permitir o parcelamento da compra. Em qualquer um dos casos a livraria mantém um cadastro
do cliente para, inclusive, informá-lo sobre lançamentos e/ou promoções que se adéquem ao
seu perfil.

Especificação de requisitos
A geração da especificação do sistema acontece logo após o levantamento de requisitos.
É no levantamento de requisitos que entendemos o que o usuário deseja.
A fase de especificação de requisitos relata os requisitos do sistema a ser desenvolvidos,
que foram levantados junto com o usuário, pelas observações realizadas no sistema atual do
cliente e na forma como os usuários interagem com ele. Como já vimos, os requisitos podem ser
divididos em funcionais e não funcionais. Para listá-los você poderá utilizar uma tabela e dividi-
los em funcionais e não funcionais.
Vamos utilizar um modelo de documentação de requisitos baseado naquele sugerido por
Wazlawick (2004), que divide e classifica os requisitos de forma organizada.
A seguir, apresentamos os requisitos funcionais descobertos até essa fase do desenvolvi-
mento.
SISTEMA LIVRARIA – VENDAS DE LIVROS

Requisitos Funcionais
Nome: Cadastrar Livro Evidente/Oculto: (E)
Descrição: O sistema deve permitir que todo livro que entra no estoque pela primeira vez seja cadastrado.

Nome: Cadastrar Cliente Evidente/Oculto: (E)


Descrição: O sistema deve permitir que todo Cliente seja cadastrado ao efetuar sua primeira compra na loja.

Claretiano - Centro Universitário


106 © Análise e Projeto de Sistemas

SISTEMA LIVRARIA – VENDAS DE LIVROS


Nome: Atualizar Estoque Evidente/Oculto: (O)
Descrição: O sistema deve permitir que a cada entrada ou saída de livro o estoque seja atualizado.

Nome: Calcular Valor a Pagar Evidente/Oculto: (O)


Descrição: O sistema deve permitir que a cada venda realizada seja calculado o valor a pagar, de acordo com o plano de
pagamento escolhido pelo Cliente.

Nome: Pesquisar Obra Evidente/Oculto: (E)


Descrição: O sistema deve permitir que o Cliente possa pesquisar sobre a obra escolhida, de acordo com o critério escolhido
por ele (por obra, por autor, por editora).

Nome: Exibir Resultado da Pesquisa Evidente/Oculto: (E)


Descrição: O sistema deve permitir que o resultado da pesquisa solicitada pelo Cliente seja mostrado na tela, ou uma
informação sobre a sua inexistência, se for o caso.

Nome: Associar Entrada de Produto no Estoque ao Pedido Evidente/Oculto: (O)


Descrição: O sistema deve permitir associar à entrada do produto no estoque, os pedidos que o aguardam para serem
atendidos, para posterior emissão de aviso de chegada do produto.

Nome: Emissão de Aviso de Chegada do Produto Evidente/Oculto: (E)


Descrição: O sistema deve permitir a emissão de aviso sobre a chegada do produto, para atendimento de pedidos relacionados
a ele.

Nome: Atendimento de Pedido sob Encomenda Evidente/Oculto: (E)


Descrição: O sistema deve fechar o pedido do Cliente feito sob encomenda, com o envio do produto a ele.
Apresentamos, também, um documento de especificação de requisitos não funcionais
para o sistema de vendas da livraria. O exemplo a seguir mostra uma sugestão para a elaboração
do documento.
SISTEMA LIVRARIA – VENDAS DE LIVROS
Requisitos Não Funcionais
Nome: Controlar Acesso Desejável/Permanente: (P)
Restrição: A função "Abrir Pedido" só pode ser acessada por operador com status de
Categoria: Segurança
"Vendedor".

Nome: Identificar Livros Desejável/Permanente: (P)


Restrição: A identificação dos livros deverá ser feita por meio de códigos de barras. Categoria: Interface

Definição dos Casos de Uso


Os primeiros Casos de Uso para o sistema de vendas da livraria são:
a) Manter Dados do Livro.
b) Manter Dados do Cliente.
c) Pesquisar Livro.
d) Efetuar Pedido de Compra.
e) Encomendar Livro.
f) Despachar Livro.
g) Pagar à Vista.
h) Pagar com Cartão de Crédito.
i) Pagar com Boleto Bancário.
A seguir, mostraremos outra forma de descrever os Casos de Uso. Conforme explicado
anteriormente, várias formas de descrição podem ser utilizadas. A forma descrita nos próximos
exemplos baseia-se naquela utilizada por Larman (2000), ou seja, a tabular.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 107

Os Casos de Uso podem ser classificados em: Casos de Uso de alto nível e Casos de Uso
expandidos.
Os Casos de Uso de alto nível são breves descrições das funcionalidades de um processo
do sistema. Devem ser usados quando a situação a ser descrita for simples, de fácil compreen-
são e não muito relevantes.
Já os Casos de Uso expandidos são aqueles descritos de forma mais detalhada. São, tam-
bém, considerados de maior relevância para o sistema.
No nosso exemplo de sistema, descreveremos o Caso de Uso Efetuar Pedido de Compra,
por ser considerado de maior relevância no contexto apresentado.
Caso de Uso: Efetuar Pedido de Compra
Atores: Vendedor, Cliente
Descrição: Vendedor informa o título do livro desejado pelo Cliente. Sistema mostra informações sobre o livro. Vendedor
informa dados sobre o Cliente. Sistema mostra informações sobre o Cliente. Sistema calcula valor da compra. Cliente escolhe
a forma de pagamento. Sistema atualiza estoque e é encerrado.
SEQUÊNCIA TÍPICA DE EVENTOS
Atores Sistema
1. Cliente informa ao Vendedor o título do livro desejado.
3. Exibe os dados sobre o livro desejado.
2. Vendedor informa título do livro ao Sistema.

4. Vendedor informa os dados do Cliente ao Sistema. 5. Exibe os dados do Cliente.


6. Cliente confirma os dados.
7. Vendedor informa dados sobre o pedido. 8. Calcula o valor do pedido.
9. Exibe as formas de pagamento.
11. Se pagamento à vista, executar o Caso de Uso "Pagar
à Vista"; se pagamento com cartão de crédito, executar
10. Cliente escolhe a forma de pagamento. o caso de uso "Pagar com Cartão de Crédito"; caso
contrário, executar o caso de uso "Pagar com Boleto
Bancário".
12. Atualiza o estoque.
13. Encerra a operação.
SEQUÊNCIA ALTERNATIVA DE EVENTOS
3.1. Livro esgotado. Encerrar operação.
3.2. Livro indisponível no estoque. Informar Cliente e encerrar operação.
3.3. Livro indisponível no estoque. Informar Cliente e executar o Caso de Uso "Encomendar Livro".
5.1. Cliente não cadastrado. Executar o Caso de Uso "Manter Dados do Cliente".
6.1. Dados não confirmados pelo Cliente. Executar o Caso de Uso "Manter Dados do Cliente".

Caso de Uso: Encomendar Livro


Atores: Vendedor, Cliente
Descrição: Vendedor informa o título do livro desejado pelo Cliente. Sistema solicita dados do Cliente. Sistema gera pedido de
encomenda do livro.
SEQUÊNCIA TÍPICA DE EVENTOS
Atores Sistema
1. Cliente informa ao Vendedor o título do livro desejado.
2. Vendedor informa título do livro ao Sistema. 3. Solicita dados do Cliente.
4. Informa dados do Cliente. 5. Abre pedido de encomenda do livro.
6. Informa a data de previsão de chegada do livro.
7. Encerra operação.
SEQUÊNCIA ALTERNATIVA DE EVENTOS
Não há.

Claretiano - Centro Universitário


108 © Análise e Projeto de Sistemas

Você foi apresentado a diferentes formas de descrição dos Casos de Uso. Agora é o mo-
mento para você escolher aquela que mais lhe agrada para descrevê-los. Aproveite para se exer-
citar, escrevendo os demais Casos de Uso apresentados nesse exemplo de sistema.

Diagrama de Casos de Uso


O diagrama de Casos de Uso deve contemplar todos os Casos de Uso do sistema. Você já
viu que podemos agrupar os Casos de Uso em pacotes.

Figura 16 Diagrama de Casos de Uso para o Sistema Livraria – Vendas de Livros.

Note que nesse diagrama estão os Casos de Uso relacionados para o sistema. Os relacio-
namentos utilizados foram os de comunicação, representados por uma linha; um relaciona-
mento de extensão, que indica que o Caso de Uso "Manter Dados do Cliente", somente será
executado se, no momento de fazer o pedido, o Cliente ainda não tiver cadastro; e, por fim, mais
três relacionamentos de extensão, que indicam que apenas um dos três Casos de Uso referentes
ao pagamento será executado.
Utilizamos, para a elaboração do diagrama de Casos de Uso, a ferramenta JUDE Community
5.4 (Model Version: 29). Entretanto, a partir do ano de 2010, o JUDE como ferramenta
de modelagem deixou de existir, e em seu lugar está o astah* community. Trata-se de uma
ferramenta para modelagem UML aberta e você pode testá-la com facilidade.
Na Unidade 7 você encontrará instruções sobre como fazer o download do software
astah* community e um tutorial sobre seu uso. Nesta unidade, você verá como construir um
Diagrama de Casos de Uso, utilizando como exemplo o Diagrama de Casos de Uso para o Sistema
Livraria.

Desenvolvimento do Diagrama de Casos de Uso – Sistema Livraria


O diagrama de Casos de Uso possui poucos elementos. Para desenvolvê-lo é necessário
saber:
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 109

a) Quem são os atores envolvidos nos Casos de Uso;


b) Quem são os Casos de Uso;
c) Se existe(m) Caso(s) de Uso com extensão/inclusão/generalização;
d) Se existe generalização entre atores.
Em resumo, os passos para a construção do diagrama de Casos de Uso são:
• Identificar Casos de Uso e atores a partir da definição de requisitos.
• Identificar as interações de Caso de Uso com Caso de Uso (extensão/inclusão/generali-
zação), Caso de Uso com ator (comunicação), e ator com ator (generalização).
• O modelo deve mostrar: todos os Casos de Uso de um determinado ator; um Caso de
Uso e todas as suas relações; todos os Casos de Uso que serão implementados para um
determinado cenário.
Todas essas informações são encontradas nos próprios Casos de uso e no documento de
especificação de requisitos. Portanto, é necessário um exame detalhado desses documentos
para a extração das informações necessárias. De posse delas, você estará pronto para iniciar o
desenvolvimento do diagrama de Casos de Uso.

Descobrindo os Casos de Uso


Para descobrir quais são os Casos de Uso envolvidos, observemos os requisitos funcionais.
Podemos fazer um agrupamento dos requisitos funcionais que estarão contemplados no mes-
mo Caso de Uso.
Observe a tabela a seguir. Ela relaciona os requisitos aos Casos de Uso. Agrupar os requi-
sitos significa que eles deverão ser implementados no mesmo processo. Por isso, primeiro agru-
pamos os requisitos, para depois, então, definirmos o Caso de Uso que os implementará.
Por exemplo, consideremos os requisitos definidos na tabela como 1 e 2. Ambos estão
associados ao Caso de Uso Encomendar Livro. Isso significa que todas as vezes que um livro for
encomendado, será necessário dar entrada desse livro no estoque (requisito 1), Quando o livro
chega à livraria, o pedido que o aguarda deve receber uma notificação, para que o mesmo possa
ser atendido (requisito 2). Portanto, ambos os requisitos serão implementados no Caso de Uso
Encomendar Livro.
Depois que os casos de uso foram definidos, devemos descobrir quem são os atores que
participam de cada um e, principalmente, quem é o ator que dispara o Caso de Uso.
REQUISITOS FUNCIONAIS CASOS DE USO
Associar Entrada de Produto no Estoque ao Pedido
Encomendar Livro
Emissão de Aviso de Chegada do Produto
Atendimento de Pedido Sob Encomenda Despachar Livro
Cadastrar livro Manter Dados do Livro
Cadastrar cliente Manter Dados do Cliente
Atualizar estoque
Efetuar Pedido de Compra
Calcular valor a pagar
Pesquisar obra
Pesquisar Livro
Exibir resultado da pesquisa
Os passos para o desenvolvimento do Diagrama de Casos de Uso do Sistema Livraria, uti-
lizando a ferramenta astah* community:
1) Abra o software astah* community.
2) Na barra de menus, escolha a opção File/New.
Claretiano - Centro Universitário
110 © Análise e Projeto de Sistemas

3) Na barra de menus da nova tela, escolha a opção Diagram/UseCase Diagram.


4) Na área de trabalho aberta, observe a barra de ferramentas que existe. Cada botão
refere-se a um elemento que pode ser utilizado na construção do diagrama de Casos
de Uso.
5) Temos dois atores no nosso sistema: Vendedor e Cliente. Vamos começar pelo dese-
nho do Vendedor, pois ele tem mais Casos de Uso associados a ele. Para desenhar o
ator, aponte o mouse para o botão Actor (note que se posicionar o mouse em cima do
botão, ele mostra o nome do botão correspondente). Dê um clique em cima do botão;
posicione o mouse na área de trabalho e dê um clique. Perceba que a figura corres-
pondente ao ator aparece. Você pode arrastá-la e posicioná-la onde quiser.
6) O nome do ator pode ser adicionado de duas formas:
a) Na própria figura. Se o nome estiver selecionado (cor azul), basta você digitar o
nome do ator. Caso ele não esteja mais selecionado, dê um clique duplo no nome
e, no modo de edição, digite o nome.
b) Observe à sua esquerda, na parte de baixo, várias paletas. A paleta Base deve es-
tar selecionada. Em Name, digite o nome do ator.
7) Observando a Figura 16, você deve, agora, desenhar os Casos de Uso. Para cada repre-
sentação de Caso de Uso, faça:
a) Aponte o mouse para o botão UseCase e proceda da mesma forma que para fazer
o desenho do ator. Um a um, escreva os nomes dos Casos de Uso (da mesma for-
ma que para o ator).
b) Para cada Caso de Uso associado diretamente ao ator Vendedor, faça uma conexão
entre o Ator e o Caso de Uso, utilizando a figura que está no botão Association.
8) Observe que o Caso de Uso Efetuar Pedido de Compra tem quatro Casos de Uso asso-
ciados a ele por meio de um mecanismo de extensão. Nesses casos, após desenhar os
Casos de Uso, clique no botão Extend. Desenhe a seta de forma que a mesma aponte
para o Caso de Uso Efetuar Pedido de Compra. Por exemplo, a seta deve ser desenha-
da do Caso de Uso Manter Dados do Cliente para o Caso de Uso Efetuar Pedido de
Compra.
9) Não se esqueça de desenhar o ator Cliente e o Caso de Uso associado a ele.
10) Lembre-se de salvar o arquivo. Para isso, escolha a opção File/Save. Escolha a pasta e
um nome para o arquivo.
11) O nome do diagrama também pode ser alterado. Para isso, logo que a área de tra-
balho do diagrama de Casos de Uso se abre, digite o novo nome no campo Name, à
esquerda da tela. Observe a Figura 17.

Figura 17 Nomeando o Diagrama de Casos de Uso para o Sistema Livraria – Vendas de Livros.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 111

11. SUGESTÕES RELEVANTES NA ELABORAÇÃO DE MODELAGEM DE CASOS DE USO


Consideramos importante deixar para você algumas sugestões que podem ser seguidas ao
elaborar a modelagem de Casos de Uso. Além de ajudar nessa importante tarefa, você começa
a adquirir hábitos que o levarão a construir modelos cada vez mais consistentes.
a) Pergunte sempre: "quais são as entradas e as saídas, juntamente com sua origem e
destino, que o sistema requer?".
b) Uma boa prática, ao escrever um Caso de Uso, é desenvolver um protótipo da(s) tela(s)
referente(s) a ele. Se ela for desenvolvida em um aplicativo, por exemplo, um editor
de apresentação, ou mesmo no próprio ambiente de programação, insira a imagem da
tela antes de iniciar os passos do Cenário Principal. A visualização da tela pode tornar
mais clara a compreensão do Caso de Uso.
c) Lembre-se de que um Caso de Uso deve sempre:
• ser iniciado por um ator;
• prover valor a um ator, ou seja, um Caso de Uso sempre deve devolver algum valor
para um ator;
• ser completo, isto é, cada Caso de Uso é uma sequência completa de cenários de
interação, mostrando como eventos são respondidos no caso.
d) Lembre-se da existência dos estereótipos, e faça uso deles quando necessário. Eles
são mecanismos utilizados para ampliar a forma de expressão dos modelos predefi-
nidos. O estereótipo é utilizado para a criação de elementos que não foram definidos
como padrão. Os tipos de estereótipos da UML são:
• estereótipos para relacionamentos de dependência;
• estereótipos para classes;
• estereótipos para eventos e mensagens;
• estereótipos para componentes;
• estereótipos para relacionamentos de generalização;
• estereótipos para restrições;
• estereótipos para comentários.
Os dois estereótipos apresentados nesta unidade são utilizados em representações de
relacionamentos de dependência.
a) O uso de pacotes em uma modelagem permite o agrupamento de Casos de Uso de
acordo com a sua natureza. Ele possibilita, também, a alocação de tarefas do proje-
to, pois os pacotes podem ser distribuídos de acordo com critérios específicos, como
unidades de entrega do sistema ou, ainda, de acordo com os perfis dos usuários ou
grupos de requisitos. Geralmente, criamos pacotes a partir de agrupamentos de Ca-
sos de Uso referentes a processos específicos de subdomínios da informação, ou por
quantidade, se for o caso, mas sempre a critério do analista.
b) Lembre-se de que o processo de descoberta de requisitos continua durante toda a
fase do desenvolvimento, pois mudanças de diversas naturezas podem ocorrer e alte-
rar as necessidades iniciais para o sistema. Se isso acontecer, a modelagem do sistema
deverá ser modificada, de forma a refletir essas mudanças.

12. QUESTÕES AUTOAVALIATIVAS


Apresentamos, a seguir, algumas questões relacionadas aos tópicos estudados nesta uni-
dade. Procure responder a todas, de forma que possa avaliar seus conhecimentos. Reflita sobre

Claretiano - Centro Universitário


112 © Análise e Projeto de Sistemas

os tópicos estudados e não se esqueça de compartilhar com seu tutor e colegas suas dúvidas. A
troca de informações permite o seu crescimento.
1) (POSCOMP – 2007) Na UML, o Diagrama de Casos de Uso proporciona uma forma de representar a aplicação
segundo a perspectiva do usuário. Considere o Diagrama de Casos de Uso para um sistema de gerenciamento
de cursos a distância apresentado na figura a seguir.

Figura 18 Diagrama de Casos de Uso.

A este respeito, analise as seguintes afirmativas.


I. O relacionamento <include> entre os Casos de Uso "Elaborar Novo Curso", "Configurar Curso" e "Selecionar
Material Didático" representa um caminho obrigatório de execução de funções da aplicação.
II. O Caso de Uso "Consultar Detalhes sobre Material Didático" só é executado se o Caso de Uso "Selecionar
Material Didático" tiver sido executado anteriormente.
III. Os relacionamentos especiais <include> e <extends> são exclusivos para Casos de Uso.
IV. A utilização de diferentes perfis de usuário (atores: "Aluno" e "Professor") é representada por meio de um
tipo de relacionamento especial chamado composição, o qual pode ser aplicado tanto a Casos de Uso como
entre atores.
A análise permite afirmar que:
a) Todas as afirmativas são verdadeiras.
b) Nenhuma das afirmativas é verdadeira.
c) Somente as afirmativas II e III são verdadeiras.
d) Somente as afirmativas III e IV são verdadeiras.
e) Somente as afirmativas I, II e III são verdadeiras.
2) Qual das alternativas a seguir não é um dos diagramas existentes na linguagem de modelagem UML (Unified
Modeling Language)?
a) Diagramas de Casos de Uso (Use Case Diagrams).
b) Diagramas de Classes (Class Diagrams).
c) Diagramas de Sequência (Sequence Diagrams).
d) Diagramas Entidade-Relacionamento (Entity Relationship Diagrams).
e) Diagramas de Estado (Statechart Diagrams).

Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:

1) e.

2) d.
© U3 – Processo de Desenvolvimento de Software – Modelagem de Casos de Uso 113

13. CONSIDERAÇÕES
Nesta unidade você teve a oportunidade de conhecer as primeiras etapas para a criação
de um sistema de software. Verificou que a Engenharia de Software considera que todo sistema,
independentemente da metodologia utilizada, possui quatro etapas de desenvolvimento: espe-
cificação, desenvolvimento, validação e evolução do software. Lembre-se de que já estudamos a
abordagem da Análise Essencial e, portanto, nesta unidade, nosso foco foi no desenvolvimento
de sistemas orientados a objetos.
Para facilitar sua compreensão, iniciamos pelas tarefas executadas na etapa da especifica-
ção. Para tanto, foi considerado um sistema para controle das vendas de uma livraria. Os passos
para desenvolver este sistema foram os seguintes: geramos a especificação do sistema, a espe-
cificação dos requisitos, o levantamento e a descrição de Casos de Uso e o diagrama de Casos
de Uso. E esses documentos recebem o nome de artefatos do sistema.
Análise, Projeto e Programação Orientados a Objeto representam tecnologias modernas,
amplamente utilizadas por empresas no desenvolvimento de novos projetos de software que
têm como objetivo atingir padrões de qualidade. A UML é a junção do que havia de melhor nas
três metodologias – Booch, OMT, OOSE. A utilização mais comum da UML é na criação de mo-
delos de sistemas de software. Todavia, ela também pode ser utilizada para representar outros
tipos de sistemas sem nenhum software envolvido.
Assim, com a UML demos início à modelagem de software orientado a objetos, iniciando
com os Casos de Uso.
Um Caso de Uso é uma técnica de modelagem utilizada para descrever o que um siste-
ma existente faz ou o que um novo sistema deve fazer. Assim, o principal caminho para você
entender o funcionamento de um sistema qualquer é descobrir como Casos de Uso e atores
interagem enviando sinais uns aos outros, pois, para compreender o papel do ator, é necessário
saber com quais Casos de Uso ele está interagindo. Temos que os principais componentes de um
Caso de Uso são: seu identificador, o ator relacionado, o objetivo, o cenário ou fluxo de eventos
principais e o cenário ou fluxo de eventos alternativos ou de exceção.
Vimos, também, que o Pacote de Caso de Uso é uma coleção de Casos de Uso, atores,
relacionamentos, diagramas e de outros pacotes, o qual é utilizado para estruturar o modelo de
Casos de Uso, dividindo-o em pares menores e, consequentemente, mais fáceis de entender.
Encerramos os estudos desta unidade com as instruções sobre os passos a serem seguidos
para a descoberta dos Casos de Uso a partir dos requisitos funcionais especificados, e também
da utilização da ferramenta astah* community para a construção de diagramas de Casos de
Uso.
Esperamos que você tenha aproveitado bem esta etapa e que esteja pronto para iniciar a
próxima unidade, que aborda um assunto importante dentro da modelagem de software orien-
tado a objetos: a modelagem de classes.

14. REFERÊNCIAS BIBLIOGRÁFICAS


BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML2. 2. ed. Rio de Janeiro: Elsevier, 2006.
BOOCH, Grady et al. UML: guia do usuário. Rio de Janeiro: Campus, 2000.
FURLAN, J. D. Modelagem de objetos através da UML. São Paulo: Makron Books, 1998.

Claretiano - Centro Universitário


114 © Análise e Projeto de Sistemas

HOUAISS. Dicionário da Língua Portuguesa. Disponível em: <http://houaiss.uol.com.br/busca.jhtm>. Acesso em: 26 set. 2008.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman,
2000.
MEDEIROS, E. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson/Makron Books, 2004.
PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Addison-Wesley, 2007.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2004.
EAD
Processo de Desenvolvimento
de Software – Modelagem de
Classes
4

1. OBJETIVOS
• Obter uma visão geral da fase de análise.
• Conhecer, identificar e modelar classes e objetos em diagramas da UML.
• Conhecer o modelo de classes.
• Entender o artefato glossário.

2. CONTEÚDOS
• Visão geral da fase de análise.
• Representação de classes: nomenclatura, atributos, operações e relacionamentos.
• Representação de objetos.
• Os estágios do modelo de classes.
• Modelo de classes: diagrama de classes e diagrama de objetos.
• Glossário.

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Para dar continuidade aos seus estudos, é importante que não fiquem dúvidas. Por
isso, sugerimos que, se necessário, retome os conteúdos vistos até o momento.
116 © Análise e Projeto de Sistemas

2) Certifique-se de ter compreendido bem os conceitos relacionados aos Casos de Uso.


Eles têm importância fundamental na descoberta das classes.
3) Antes de iniciar o desenho de um diagrama de classes, procure entender bem de que
forma as classes podem ser relacionar.
4) Lembre-se que a modelagem de um software é feita a partir de vários diagramas. De
nada adianta saber utilizar uma ferramenta para desenhar um diagrama se os concei-
tos aplicados a ele não estiverem bem compreendidos.
5) Se encontrar dificuldades, não desanime. Entre em contato com seus colegas de curso
e com seu tutor. Faça parte desta comunidade colaborativa de conhecimento.
6) Você pode verificar no seu dia a dia que cada objeto tem identidade própria, em que
duas coisas, mesmo que exatamente iguais, não podem ser consideradas idênticas,
pois, minimamente, não ocupam o mesmo lugar no espaço.
7) Foi apresentada uma forma de identificação de classes por meio da técnica de aná-
lise dos casos de uso. Procure outras formas de identificação de classes utilizando
esta mesma técnica. Depois, veja mais algumas técnicas diferentes da apresentada.
Se você encontrar dificuldades, não desanime! Seu tutor e colegas podem ajudá-lo no
esclarecimento de suas dúvidas.
8) Depois de criado o modelo de classes de análise, faça uma comparação entre ele e
o modelo de casos de uso para verificar a consistência entre os dois modelos (por
exemplo, classes que não participam da realização de casos de uso é um tipo de in-
consistência).

4. INTRODUÇÃO À UNIDADE
A Unidade 3 apresentou as etapas para o desenvolvimento de um software, indepen-
dentemente de sua abordagem. Além disso, apresentou os primeiros conceitos relacionados à
abordagem da análise e projeto orientados a objetos. Teve a oportunidade também de conhecer
uma UML e os diversos diagramas que ela contém e estudou, ainda, como são levantados os
requisitos para um sistema e, a partir deles, construir os casos de uso e o diagrama de casos de
uso.
Esta unidade trata dos aspectos de desenvolvimento de software relacionados à fase da
análise. Além de entender as atividades compreendidas nesta fase, você aprenderá a identificar
e modelar classes e objetos em diagramas da UML. Estudará, em detalhes, a modelagem das
classes, que são os elementos mais importantes da Orientação a Objetos.
É fundamental que você saiba que o modelo de classes refere-se ao aspecto estrutural
estático do sistema. Portanto, continuando pelo ciclo de desenvolvimento de sistemas, estu-
daremos a fase da análise, aprofundando as atividades que são desenvolvidas e os artefatos
produzidos.

Problematizando o tema
Como se configura uma classe de objetos em um domínio de estudo de determinado siste-
ma? Por que as classes são tão importantes? É possível uma classe existir sozinha, ou ela pode se
relacionar com outras? Reflita sobre estas questões, considerando o conhecimento prévio que
possui, e fique atento ao texto desta unidade, buscando a resposta para elas.
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 117

5. VISÃO GERAL DA FASE DE ANÁLISE


A fase de análise está relacionada à compreensão dos requisitos para a descoberta da so-
lução do problema proposto pelo sistema.
Vimos, na unidade anterior, que os requisitos são descritos em um documento chamado
especificação de requisitos. Assim como os requisitos, é necessário que o desenvolvedor, após
compreender o problema, gere uma declaração sobre ele.
Esse documento é denominado especificação do sistema, que pode ser escrito em lingua-
gem natural ou em linguagem estruturada. Escrever em linguagem natural significa descrever o
problema sob a forma de texto, e a desvantagem em descrever dessa forma são os enunciados
ambíguos, incompletos e inconsistentes.
O uso de uma linguagem estruturada limita um pouco a forma de escrever, porém, pa-
droniza a maneira como os requisitos são redigidos. Baseia-se na utilização de formulários ou
templates para especificar os requisitos.
A fase de análise é uma etapa importante no processo de desenvolvimento. Podemos di-
zer que o sucesso do sistema está fortemente relacionado a um bom trabalho de análise. Todo
este trabalho tem como objetivo principal a construção de modelos. Bons modelos traduzem-se
em sistemas confiáveis e eficientes, uma vez que por meio deles podemos obter um profundo
entendimento dos requisitos.
É importante ficar claro que a análise deve especificar "o que" será feito no sistema, ou
seja, não há ainda a preocupação de "como" será feito. O resultado produzido nesta fase são os
modelos (artefatos) que especificam o sistema.
Segundo Blaha e Rumbaugh (2006), a fase de análise pode ser dividida em duas etapas:
análise de domínio e análise da aplicação. A análise de domínio trata dos conceitos e relações
que são de conhecimento dos especialistas no domínio, ou seja, no qual se obtém conhecimen-
to sobre a aplicação que será desenvolvida. Como artefatos, são gerados os modelos de classes
e os modelos de estados (se houver necessidade). A análise da aplicação trata dos aspectos
computacionais da aplicação que são visíveis ao usuário, e o modelo de interações é o artefato
produzido.
No decorrer desta unidade, você estudará o modelo de classes e poderá perceber que a
análise de domínio interessa-se pelos objetos do mundo real e suas relações com o sistema. Já a
análise da aplicação preocupa-se com os aspectos computacionais sob a perspectiva do usuário,
ou seja, com a forma como o usuário vê os objetos da aplicação.

6. INTRODUZINDO OS CONCEITOS DE CLASSE, OBJETO, ATRIBUTOS E MÉTODOS


Para iniciar nosso estudo de Análise e Projeto Orientados a Objeto, devemos entender o
conjunto de informações específicas ao âmbito do projeto que desejamos desenvolver, propondo
uma solução em termos de software. Este conjunto é chamado de domínio do problema, o qual é
composto por um conjunto de objetos que têm atributos e comportamentos específicos.
Por exemplo, se quisermos propor um software para armazenar uma questão de múltipla
escolha, da disciplina Matemática, do professor Paulo, para o aluno Joel, o domínio da informa-
ção será o conjunto de fatos que abrange a questão de múltipla escolha da disciplina, o profes-
sor e o aluno.

Claretiano - Centro Universitário


118 © Análise e Projeto de Sistemas

Nessa situação, teremos os seguintes objetos envolvidos: questão de múltipla escolha;


matemática; Paulo; Joel. Desta forma, percebemos que todos esses objetos possuem atributos
ou elementos descritivos qualificadores que podem ser específicos para cada tipo de objeto. Um
aluno, por exemplo, possui os atributos: nome, idade e número da matrícula.
Os objetos identificados no domínio do problema deverão ser manipulados por meio de
uma coleção de funções, também chamadas de métodos, operações ou serviços. Para tanto,
será preciso inserir dados do professor, da questão e do aluno. É possível que realizemos, tam-
bém, alguma alteração ou, ainda, que tenhamos que excluir dados de algum objeto. Dessa for-
ma, os métodos identificados no domínio do problema para esses objetos serão os seguintes:
inserir, alterar e excluir.
Todavia, além da questão de múltipla escolha, da disciplina Matemática e do aluno Paulo,
é possível que, com o passar do tempo, sejam registradas outras questões, outras disciplinas e
outros alunos. Portanto, novos objetos poderão, eventualmente, ser criados.
Para resolver este problema, vamos, inicialmente, categorizar os objetos em classes e em
subclasses.
Você saberia definir o que é uma classe? Pois bem, uma classe é um conjunto de objetos
que compartilham uma estrutura e um comportamento comum. Um objeto é simplesmente
uma instância de uma classe.
Veja que a Figura 1, disposta a seguir, representa a ideia de classe como gabarito para
instanciar objetos.

Figura 1 Representação abstrata de uma classe.

Mas, voltando ao nosso problema anterior, as classes identificadas para ele são: Questões,
Alunos, Disciplinas, Professores.
Ao inserir o aluno Paulo, criamos ou instanciamos um novo objeto da classe Alunos. Ao
criar outro novo aluno, por exemplo, Pedro, teremos outro objeto, que também é outra instân-
cia dessa mesma classe, com os mesmos atributos e métodos dos outros objetos que foram
criados com base na classe Alunos
A utilização do conceito de classes permite que o Analista de Sistemas abstraia caracterís-
ticas de um problema, que propicia à modelagem a capacidade de generalizar componentes de
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 119

software a partir de alguns casos específicos. Por exemplo, em um dado caso, identificamos as
classes: carro de passeio, carro esportivo e carro rural. Esses três tipos podem ser abstraídos em
uma classe genérica chamada veículo.
É possível, também, que algum objeto tenha que se comunicar com outro, o que pode
acontecer por diversas razões. Essa comunicação ocorre por meio de um protocolo de men-
sagens. Mas, não se preocupe com isso neste momento, pois este assunto será detalhado na
próxima unidade.

7. CONCEITOS FUNDAMENTAIS NO PARADIGMA DA ORIENTAÇÃO A OBJETOS


O paradigma da orientação a objetos apresenta os seguintes conceitos fundamentais:
a) Identificação.
b) Classificação.
c) Herança.
d) Polimorfismo.
e) Encapsulamento.
A seguir, observe, de maneira detalhada, a descrição desses conceitos.

Identificação
Cada objeto tem identidade própria, ou seja, dois objetos são diferentes, mesmo que seus
dados e suas operações sejam idênticos, pois dois objetos, mesmo que idênticos, não ocupam
o mesmo lugar no espaço. Essa correspondência, também, existe em um sistema computacio-
nal, visto que cada objeto deverá ocupar um endereço único de memória e possuir um nome
(identificador) único. Por exemplo, de acordo com o nosso problema, o objeto Paulo deverá ser
único para o sistema.

Classificação
É um processo inerente ao dia a dia do ser humano. Se você parar para pensar, descobrirá
que hoje utilizou o processo de classificação inúmeras vezes. Por exemplo:
• Na escolha da roupa que vestiu (roupa esporte, social, de inverno, de verão etc.);
• Na escolha do alimento que ingeriu etc.
Na Orientação a Objetos, classificar significa agrupar objetos em classes, uma vez que se
observou que eles possuem dados e operações semelhantes.
Portanto, o processo de classificação é importante dentro da Orientação a Objetos, dado
que é por meio dessa classificação que serão criadas as classes do software. Conforme vimos
em um exemplo anteriormente, os objetos do software serão instanciados a partir das classes
criadas.

Herança
O conceito de Herança nada mais é que o compartilhamento de atributos e operações
entre classes. Isso acontece a partir de um relacionamento hierárquico. Por exemplo, uma clas-
se pode ser definida de maneira abrangente (superclasse) e depois ser refinada em subclas-
ses. Portanto, há uma hierarquia ou subordinação da subclasse para a classe mais abrangente.
Atente-se para o fato de que as propriedades de uma superclasse não precisam ser repetidas em
uma subclasse, visto que elas, automaticamente, herdam todas estas propriedades.
Claretiano - Centro Universitário
120 © Análise e Projeto de Sistemas

Agora, vamos voltar ao exemplo dos alunos. Poderíamos generalizar as classes ALUNOS e
PROFESSORES na superclasse PESSOAS. Então, ALUNOS e PROFESSORES seriam as subclasses.
Portanto, a classe PESSOAS é a classe hierarquicamente superior (superclasse), mais genérica,
e as classes ALUNOS e PROFESSORES, as classes hierarquicamente inferiores, mais específicas
(subclasses).
Observe que a classe PESSOAS possui os seguintes atributos: nome, data de nascimento e
número da identidade. E os métodos dessa classe são: inserir, alterar e excluir pessoas. Basea-
dos nesta classe, criamos a subclasse ALUNOS, que, por sua vez, herdaria os mesmos atributos
e métodos, já que um aluno não deixa de ser uma pessoa.
Dessa forma, a subclasse ALUNOS teria, também, outros atributos específicos de um alu-
no, como número da matrícula e curso, e, além dos métodos herdados da classe PESSOAS, teria
um método específico: fazer prova. O mesmo vale para a subclasse PROFESSORES, que herda os
atributos e os métodos da classe PESSOAS e poderia ter atributos específicos, como, por exem-
plo, a sua titulação, e um método específico seria: montar questão de múltipla escolha.

Polimorfismo
Polimorfismo é uma palavra derivada do grego que significa muitas (poli) formas (morfos).
Em Orientação a Objetos, o conceito de polimorfismo significa que uma mesma operação
pode se comportar de maneira diferente, dependendo do estímulo recebido e das classes nas
quais se encontra. De acordo com este conceito, as classes derivadas de uma mesma superclas-
se podem herdar operações que tenham comportamentos diferentes em cada subclasse, produ-
zindo resultados diferentes, dependendo de como cada objeto implementa a operação.
Veja o exemplo de uma superclasse APLICAÇÃO, com um método chamado "saldo". Supo-
nha que esta superclasse dê origem às classes POUPANÇA e RENDA FIXA. O método saldo terá
comportamentos diferentes em cada classe. Portanto, no ambiente polimórfico, todas as classes
podem conter uma mesma operação, mas ela pode ser implementada por métodos particulares
em cada classe.

Encapsulamento
Lembrando do significado da palavra cápsula, que significa "recipiente", compreendemos
que encapsular é como uma operação na qual guardamos algo, promovendo o isolamento des-
se objeto, o que possibilita a proteção dele em relação ao comportamento de outro objeto
implementado. Isso é uma vantagem no que diz respeito à proteção e à propagação de erros,
favorecendo até a diminuição no esforço de manutenção. O encapsulamento também promove
a ocultação do usuário dos detalhes de implementação do objeto.

8. CLASSES
Estudaremos agora, com mais profundidade, um dos elementos mais importantes da
Orientação a Objetos: as classes.
Como você viu anteriormente, em uma visão simplificada, é como se uma classe fosse um
gabarito ou molde, a partir do qual os objetos do sistema são criados.
Muitas são as definições para classes. Formalmente, uma classe é a descrição de um tipo
de objeto. Em outras palavras, uma classe são agrupamentos, também chamados de categorias
ou grupos, de tipos de objetos com os quais interagimos no nosso dia a dia.
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 121

Segundo Blaha e Rumbaugh (2006, p. 24), "uma classe descreve um grupo de objetos com
as mesmas propriedades (atributos), comportamento (operações), tipos de relacionamentos e
semântica". É a unidade básica de representação gráfica e de implementação.
Um diagrama de classes é construído por um Analista de Sistemas para descrever a visão
estática do sistema com relação a classes e relacionamentos entre elas. Pode-se dizer que o
diagrama de classes ajuda a definir a base, para que os demais diagramas apresentem outras
visões do sistema. Além disso, serve de apoio para a construção de outros diagramas, tais como
o diagrama de sequência e o diagrama de objetos.

Representação gráfica de uma classe


Uma classe é representada graficamente por um retângulo dividido em três compartimen-
tos:
• O primeiro para identificação, ou seja, o nome da classe;
• O segundo para a especificação da relação de seus atributos;
• O terceiro para especificar os métodos ou operações de manipulação de dados e de
comunicação de uma classe com outras classes do sistema.

nomeDaClasse

- nomeDosAtributos e tipo: opcional

+ nomeDasOperacoes() : opcional

Figura 2 Representação gráfica de uma classe.

A sintaxe utilizada para descrever o conteúdo de cada compartimento é independente de


linguagem, embora possam ser utilizadas outras sintaxes, como a do C++, Java etc.
Por exemplo:
Em programação Java, adota-se o padrão em que as classes devem ter todas as palavras
que formam o seu nome iniciadas em letra maiúscula (ExemploNomeClasse) observando a au-
sência de espaço ( ) ou (_) entre as palavras.
Para o caso de atributos e métodos, convém que eles tenham a primeira letra minúscula
e a primeira letra da segunda palavra em diante, maiúscula; observa-se, também, a ausência de
espaço ( ) ou (_) entre as palavras. Veja a sintaxe a seguir:
• exemploAtributo;
• exemploMetodo().
A seguir, você verá a descrição de cada compartimento de uma classe, conforme foi apre-
sentado na Figura 2.

Nome da classe
É conveniente que o identificador (nome) da classe seja:
• Derivado do domínio da aplicação;
• Menos ambíguo possível;
• Substantivo e que não contenha prefixos ou sufixos.

Claretiano - Centro Universitário


122 © Análise e Projeto de Sistemas

Depois de identificar os objetos (ou conceitos) pertinentes ao domínio do problema, é


necessário definir as propriedades que queremos representar. Essas propriedades podem ser
dados (atributos) ou operações.

Atributos de uma classe


De maneira geral, pode-se afirmar que os atributos são tipos de informações específicas
de um dado objeto, instanciado ou categorizado, a partir de uma classe.
Um atributo representa uma propriedade que todos os objetos da classe têm (por exem-
plo: todas as mesas têm altura, número de pernas, posição na sala etc.), mas cada objeto possui
valores particulares para seus atributos (continuando nosso exemplo: algumas mesas são muito
baixas, outras são altas, de madeira, de plástico etc.).
Vale a pena ressaltar que somente os atributos que interessam ao sistema devem ser re-
presentados.
Veja, a seguir, quatro propriedades importantes que os atributos podem apresentar:
1) Visibilidade: é o escopo do atributo: pode-se especificar o quão acessível é um atri-
buto de um objeto a partir de outros objetos. A visibilidade é uma informação, e é
opcional. Os sinais ou símbolos de visibilidade, assim como suas descrições, podem
ser observados no Quadro 1:
Quadro 1 Símbolos e seus significados na visibilidade.
SINAL OU SÍMBOLO DE
DESCRIÇÃO DA VISIBILIDADE
VISIBILIDADE

- Privativo – nenhuma visibilidade externa, ou seja, não é visível às outras classes.

Público – visibilidade externa total. Todos têm acesso, e o atributo pode ser utilizado por
+
operações declaradas dentro de outras classes.

# Protegido – visibilidade externa limitada.

2) nomeDoAtributo: é um identificador para o atributo.


• Tipicamente a nomeação de um atributo se inicia com uma letra minúscula;
• Concatena-se com as demais palavras que compõem o nome, iniciando com letras
maiúsculas.
3) Propriedade: apresenta características aplicáveis ao elemento. A propriedade é uma
informação, e é opcional. Observe, a seguir, os itens que devem ser informados:
a) Descrição: informe descrição sucinta da propriedade;
b) Tipo de dado: informe o tipo do atributo (inteiro, real, caractere, outra classe
etc.;
c) Tipo de atributo: informe se o tipo de atributo é estático, constante, normal (não
estático e não constante), matriz, atributo final (utilizado em Java);
d) Domínio de valores: informe o valor mínimo e o valor máximo (finito ou infinito),
bem como a restrição, se houver.
4) Valor_default (ou valor inicial): pode-se especificar um valor inicial para o atributo. O
valor default é uma informação e é opcional.

Operações de uma classe


Uma operação também é referida como método. Entretanto, temos que a palavra mé-
todo é mais adequada à implementação ou programação. Quanto ao termo operação, é mais
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 123

abstrato e designa um serviço que os objetos devem cumprir. Em termos computacionais, ope-
ração é algo invocado por um objeto (procedimento de chamada), e método é a implementação
de uma operação. Portanto, as operações são executadas sempre que um objeto recebe uma
mensagem de outro objeto.
Veja, então, que as operações podem mudar os valores dos atributos do objeto que a efe-
tua, ou não. Por exemplo, podemos inserir, alterar ou excluir dados de alunos etc. Uma classe,
também, pode ter qualquer número de operações.
Portanto, segundo Blaha e Rumbaugh (2006, p. 27), "uma operação é uma função ou um
procedimento que pode ser aplicado a ou por objetos em uma classe". Uma mesma operação
pode ser aplicada a diferentes classes. O método é a implementação de uma operação para uma
classe.
Para melhor compreender a diferença entre operação e método, vejamos o seguinte
exemplo. Imagine uma operação chamada desenhar. Essa operação pode ser implementada
com códigos diferentes, dependendo do que vai ser desenhado quando ela for chamada. Pode
ser o desenho de um círculo, de um retângulo, e assim por diante. Isso significa que uma única
operação pode ser implementada por diferentes métodos.
Como os atributos, duas operações em duas classes podem ter o mesmo nome, o que é
denominado de polimorfismo, ou seja, a mesma operação está implementada em dois métodos
diferentes, em duas classes.
Observe a seguir, na Figura 3, os exemplos das classe Usuários, Avaliações e Questões.
Vamos retomar o caso proposto na unidade anterior sobre um software educacional. Re-
lembrando que o objetivo é desenvolver um programa que auxilie no processo de avaliação de
conteúdos ensinados pelo professor, oferecendo funcionalidades de montagem e aplicação de
avaliações com questões de múltipla escolha, disponibilizando, também, a correção automática
da avaliação para o professor e para os alunos, bem como a geração de relatórios de desempe-
nho de alunos, e que, além disso, controle o acesso aos usuários por questões de segurança.
Três classes foram identificadas:
• Usuários (generalização das classes: Aluno, Professor, Administrador).
• Avaliação.
• Questão.
O Diagrama de Classes preliminar do sistema está representado na figura a seguir.
Usuário Av aliações Questões
- codigoUsuario: int - codigoAvaliacao: int - alternativaA: int
- emailUsuario: int - alternativaB: int
- dataAvaliacao: int
- loginUsuario: int - alternativaC: int
- tituloAvaliacao: int
- nomeUsuario: int - alternativaD: int
- senhaUsuario: int - codigoQuestao: int
+ alterarAvaliacao() : void
- tipoUsuario: int - respostaCorreta: int
+ consultarAvaliacao() : void
- tituloQuestao: int
+ alterarUsuario() : void + excluirAvaliacao() : void
+ consultarUsuario() : void + inserirAvaliacao() : void
+ alterarQuestao() : void
+ excluirUsuario() : void + liberarAvaliacao() : void + consultarQuestao() : void
+ inserirUsuario() : void + listarDesempenhoAluno() : void + excluirQuestao() : void
+ logarSistema() : void + listarDesempenhoAvaliacao() : void + inserirQuestao() : void

Figura 3 Representação gráfica das classes do sistema gerenciador de avaliações.

Claretiano - Centro Universitário


124 © Análise e Projeto de Sistemas

Relacionamentos entre classes


Ao elaborarmos um diagrama de classes, procuramos representar todas as classes do sis-
tema, bem como todos os relacionamentos que existem entre elas. Veja, a seguir, os tipos de
relacionamentos existentes:
a) Associação;
a) Agregação e composição;
b) Generalização e especialização;
c) Realização.
Observe esses tipos de associação com atenção. Você verá uma grande correspondência
com a modelagem de dados do tipo entidade-relacionamento.

Associação
Uma associação é a ligação entre classes. A partir de uma associação, na qual são co-
nectadas duas classes, você é capaz de navegar do objeto de uma classe até o objeto de outra
classe.
Podemos encontrar este tipo de associação, também, em nosso cotidiano. É praticamente
impossível não encontrar algum tipo de ocorrência que possa conectar um objeto a outros. Por
exemplo, uma pessoa trabalha para uma companhia; uma companhia tem vários escritórios, e
assim por diante.
A associação, portanto, é a documentação do relacionamento entre dois objetos. Para
melhor documentar uma relação, podem-se incluir nomes, destacar os papéis que cada objeto
executa na relação, indicar a direção e, também, a multiplicidade desse relacionamento.
Vamos, a seguir, verificar os itens de informações que documentam uma relação.
Começaremos pelo nome de uma associação, ele é importante porque descreve a própria
natureza do relacionamento.
Em uma associação, muitas vezes a informação é mais bem documentada quando indica-
mos o papel que cada classe executa na relação. Por exemplo, uma relação "Pessoa trabalhar
Empresa" poderia ser melhor explicada indicando-se o papel de Pessoa, que é trabalhador, e o
papel da Empresa, que é de empregador.

Figura 4 Representação gráfica de papéis em uma associação de classes.

Em seguida, temos a questão da direção.


A direção de uma associação é importante porque orienta a navegação da informação. É
possível que haja apenas um sentido (unidirecional) ou, então, que a associação seja navegável
em duas direções (bidirecional). Desta forma, o traço que une as duas classes passa a ser uma
seta que apontará para uma ou para as duas classes.
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 125

Por último, temos a multiplicidade.


A multiplicidade, também chamada de cardinalidade, é o número de ocorrências entre um
objeto qualquer da classe e os demais objetos da outra classe envolvida.
Portanto, ela determinará a quantidade de objetos que podem ser conectados ou partici-
par de um relacionamento. A multiplicidade é a quantidade de vezes em que se repete o papel
de uma associação, e é escrita como uma expressão equivalente a um valor explícito ou a um
intervalo de valores.
Ela pode ser apresentada de várias maneiras, veja a seguir:
(0) – zero;
(1) – exatamente uma ocorrência (no mínimo e no máximo);
(N) – sendo N um número exato;
(*) – muitas ocorrências (no mínimo e no máximo);
(0 ... 1) – zero (nenhuma) ou, então, no máximo uma ocorrência;
(0 ... *) – zero (nenhuma) ou, então, várias ocorrências;
(1 ... N) – no mínimo uma ou, então, um número exato;
(1 ... *) – no mínimo uma ou, então, várias ocorrências.
No caso do Sistema Gerenciador de Avaliações de Questões de Múltipla Escolha, o profes-
sor cria questões de múltipla escolha. Veja como ficaria a representação gráfica na Figura 5.

Figura 5 Representação gráfica do relacionamento das classes professor e questões.

Um professor cadastrado no sistema pode não ter nenhuma questão cadastrada, como
também, pode ter infinitas (0 .. *). Todavia, havendo uma questão cadastrada, é obrigatório que
tenha um único professor que a cadastrou (1).

Associação Recursiva
Agora que você compreendeu o que é uma associação, definiremos a associação recursiva.

Claretiano - Centro Universitário


126 © Análise e Projeto de Sistemas

A recursividade em uma relação é um caso bem interessante, pois ela ocorre quando a
outra classe associada é a própria classe.
Por exemplo:
Imagine que tenhamos a seguinte situação para modelar: João é casado com Maria. João
e Maria foram abstraídos em uma classe PESSOA. Portanto, PESSOA é casada com PESSOA.
Graficamente, representamos a recursividade com um traço apontado para a própria clas-
se. Observe o exemplo a seguir, para que você compreenda melhor como acontece a represen-
tação de papéis.

+Marido

Pessoa casar
com

+Esposa

Figura 6 Representação gráfica de uma associação recursiva.

Agregação e Composição
Agregação e composição são tipos especiais de associação.
A agregação é um tipo de relacionamento no qual duas classes estão inseridas em um
contexto "todo-parte", entre pares (um objeto não é mais importante que o outro). É um rela-
cionamento em que um objeto contém o outro. As classes deste tipo de relacionamento podem
viver de forma independente, de forma que os objetos da parte constituinte ou da agregada
sejam independentes com relação à vida, porém ambas pertencem a um único todo.
Um exemplo de relacionamento por agregação ocorre entre as classes Carro (todo) e Peça
(parte). Um carro é formado por peças. Entretanto, se o carro deixar de existir, as peças podem
continuar existindo.
Para chegarmos a este nível de análise, dependeremos de um estudo aprofundado do
domínio do problema.
Graficamente, a agregação é representada por um losango sem preenchimento, conforme
demonstra a Figura 7.

Figura 7 Representação gráfica de uma agregação.

Entretanto, há um caso particular de agregação que é muito utilizado. Trata-se do caso


composição. Ele ocorre quando duas classes só têm sentido no momento em que estiverem
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 127

associadas. Isso implica que, se uma instância da classe deixar de existir, todas as outras associa-
das por composição "deixarão" de existir também. Exemplos comuns desse tipo de associação
no nosso dia a dia são a Nota Fiscal e o Recibo de Locação de Filme.
Nesses exemplos, há uma associação entre um bloco de informação mais genérico, que
relaciona, por exemplo, a identificação, a organização e a data, e outro bloco de informações
mais específicas, que são os itens relacionados nestes tipos de documentos. Na Nota Fiscal, por
exemplo, associamos cabeçalho e item de nota fiscal.
Graficamente, o símbolo que representa a composição é um losango preenchido.
No caso do Sistema Gerenciador de Avaliações, há uma relação de agregação entre Avalia-
ção e Questão. Afinal, uma avaliação só tem sentido se houver questões a serem respondidas.
As questões não podem ser respondidas individualmente, sem estarem vinculadas a uma ava-
liação específica. Observe a demonstração da composição na Figura 8.

Figura 8 Representação gráfica da composição no sistema gerenciador de avaliações – Avaliações e Questões.

Generalização e Especialização
De acordo com os conteúdos estudados você pode estar se perguntando: o que é gene-
ralização e especialização? Você, possivelmente, deve ter aprendido esses conceitos na disci-
plina Banco de Dados, na Modelagem Entidade-Relacionamento, na notação conhecida como
"extendida". Generalização é um tipo de associação que modela o conceito de herança entre
classes, indicando quais objetos foram abstraídos em classes e, com um estudo mais aprofun-
dado, percebeu-se que essas classes poderiam ser abstraídas em uma classe mais genérica, daí
o nome generalização.
Portanto, a generalização é um relacionamento entre as superclasses e suas subclasses.
Essas subclasses também podem ser chamadas de classes-filha, pertencendo a uma hierarquia
inferior à classe-mãe. Neste relacionamento, a subclasse herda todas as propriedades da super-
classe, seus atributos e operações.
No caso do Sistema Gerenciador de Avaliações, percebemos que os atores do sistema
foram generalizados no ator usuários. Os atores de um sistema em UML são diretamente mode-
lados em classes. Analise a representação gráfica na Figura 9.

Claretiano - Centro Universitário


128 © Análise e Projeto de Sistemas

Figura 9 Representação gráfica de generalização de classes–Usuários.

Especialização é como se o processo de generalização ocorresse ao contrário. Para você


entender melhor, imagine que objetos foram abstraídos em uma classe genérica e, com um es-
tudo mais aprofundado, percebeu que essa classe poderia ser desdobrada em duas outras mais
específicas. Daí o nome de especialização.
Graficamente, não há diferença entre a generalização e especialização. É praticamente
uma questão de ponto de partida da abstração, se as classes foram generalizadas ou foram
especializadas. Portanto, a representação gráfica do processo é idêntica. Observe, no caso da
generalização, que as operações de manutenção de dados de usuários são específicas para a
classe Administrador.
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 129

Figura 10 Diagrama de classes do sistema gerenciador de avaliações.

9. OBJETOS
Um diagrama de objetos apresenta um conjunto de objetos e seus relacionamentos em
determinado ponto no tempo. Estes diagramas mostram os objetos de um sistema funcionando
em uma determinada ocasião temporal. Com isso, temos uma visão estática do projeto ou de
um processo do sistema.
Vamos fazer uma analogia com um jogo de futebol: são 22 jogadores correndo atrás de
uma bola em um campo limitado, seguindo regras estabelecidas. Se você congelar a imagem em
certo momento do jogo e analisar cada jogador individualmente, poderá determinar o que cada
um está fazendo naquele instante. Perceba que estes jogadores colaboram uns com os outros,
seguindo uma estratégia, para marcar o gol.
Tentar visualizar, analisar, construir ou documentar um sistema complexo, é semelhante à
situação do jogo de futebol. Se tentarmos entender apenas um processo do sistema de forma
isolada, podemos perder a visão global, quanto ao modo como as partes do sistema estão orga-
nizadas e interagem entre si. Ao contrário disso, é necessário estudar um retrato do objeto, seus
vizinhos e seus relacionamentos entre eles.
Graficamente, os objetos são diferenciados de suas classes por terem seus nomes subli-
nhados. Cada objeto tem o nome da seguinte forma: nome da instância: nome da classe.
Embora menos importante que o diagrama de classes, o diagrama de objetos pode ajudar
a compreender diagramas complexos que não estejam muito claros. Para tanto, os diagramas de
objetos costumam conter os seguintes elementos:

Claretiano - Centro Universitário


130 © Análise e Projeto de Sistemas

• Objetos.
• Vínculos.
Um diagrama de objetos é essencialmente uma instância de um diagrama de classes, por-
tanto, é comum incluir nestes diagramas as classes do sistema que estão por trás de cada ins-
tância.
Observe, na Figura 11, a representação de um diagrama de objetos.

Figura 11 Representação de um diagrama de objetos.

Em Booch et al. (2000, p. 197), são apresentadas algumas dicas para modelar uma estru-
tura de objetos:
a) Identifique o mecanismo cuja modelagem você deseja fazer. Saiba que um mecanismo
representa uma função ou comportamento da parte do sistema cuja modelagem você
está realizando, e que é resultante da interação de um conjunto de classes.
b) Para cada mecanismo, identifique as classes e outros mecanismos que participam des-
ta colaboração. Também, identifique os relacionamentos.
c) Analise um único cenário neste mecanismo, congelando-o em um determinado mo-
mento.
d) Exponha o estado e os valores dos atributos de cada um destes objetos para com-
preensão do cenário. Do mesmo modo, exponha os vínculos existentes entre estes
objetos.
A seguir, seguem algumas dicas e sugestões de um diagrama de objetos bem estrutura-
do:
1) Ter o foco voltado para comunicar um único aspecto da visão estática;
2) Conter somente aqueles elementos essenciais para compreensão desse aspecto;
3) Ter um nome capaz de comunicar seu propósito;
4) Distribuir seus elementos para minimizar a ocorrência de linhas cruzadas;
5) Possuir anotações e cores para chamar a atenção das características importantes no
seu diagrama.

10. OS ESTÁGIOS DO MODELO DE CLASSES


O modelo de classes é considerado o mais importante para o desenvolvimento de um sis-
tema, uma vez que ele se modifica durante todo o processo. Na fase de análise, ele tem como
objetivo descobrir e representar os conceitos (objetos).
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 131

Embora o modelo de classes seja considerado o mais importante, vale ressaltar que a base
para a sua construção vem dos casos de uso, o que significa que, por meio dos casos de uso,
conseguimos descobrir os conceitos relacionados ao domínio da aplicação.
O modelo de classes possui três estágios: análise, projeto e implementação. Observe a
seguir a descrição de cada um deles.

Classes de análise
São as primeiras classes a serem descobertas. Surgem na fase da investigação e seus obje-
tos são descobertos nas fases de análise de domínio e de aplicação. O modelo que as representa
é denominado modelo de classes de análise. Ele é construído na fase de análise e, portanto, não
considera as restrições tecnológicas.
Nesta fase, o modelo de classes também é conhecido por modelo conceitual. Ele descre-
ve a informação que o sistema vai gerenciar, e serve como base para a criação do diagrama de
classes de projeto, relacionado com a arquitetura do software. Por isso, o modelo conceitual é
um artefato do domínio do problema (fase de análise), ao contrário do diagrama de classes de
projeto, que é um artefato que pertence ao domínio da solução.
Ao trabalharmos no modelo conceitual, a preocupação é de descobrir os conceitos (as in-
formações que o sistema deverá gerenciar). Ou seja, os elementos nele descritos correspondem
a informações que, inicialmente, encontram-se apenas na visão do usuário. Ele é independente
da solução física, relacionada ao domínio do problema. O modelo conceitual não depende da
solução física, a qual se relaciona ao domínio do problema, pois o modelo conceitual é livre de
restrições tecnológicas.
O modelo conceitual é único para todo o sistema. Ele pode se modificar ao longo do de-
senvolvimento, conforme os ciclos iterativos vão se completando. Por representar o aspecto
estático da informação, o modelo conceitual não faz referências a operações, nem a aspectos
dinâmicos do sistema.
Três elementos representam a informação, quando se trata de diagramas de classes do
modelo conceitual:
• Conceitos: são as próprias classes.
• Atributos: são as informações ligadas aos conceitos. São as propriedades dos conceitos.
• Associações: ligam os diferentes conceitos entre si.

Classes de projeto
As classes de projeto derivam das classes de análise e são representadas pelo modelo de
classes de projeto. Este modelo é construído na fase de projeto, quando se procura descobrir
como a solução encontrada na fase de análise será desenvolvida.

Classes de implementação
São representadas pelo modelo de classes de implementação e correspondem à imple-
mentação das classes em uma linguagem de programação, normalmente orientada a objetos.

Claretiano - Centro Universitário


132 © Análise e Projeto de Sistemas

11. DESCOBRIR AS CLASSES


Há várias técnicas que auxiliam na descoberta das classes na fase de análise. Entretan-
to, vamos nos ater a apenas uma delas. Trata-se da análise dos casos de uso, que se utiliza do
modelo de casos de uso para tal fim. Cada caso de uso deve ser analisado para que as classes
sejam identificadas. Essa técnica se baseia no princípio de que, se uma classe existe, é porque
ela participa do sistema.
Os objetos participantes do sistema podem ser divididos em três categorias: fronteira
(boundary), controle (control) e entidade (entity). A UML dispõe de notação gráfica para a sua
representação. Observe a seguir.

Figura 12 Notação da UML para as classes de análise.

Agora vamos descrever as três categorias dos objetos participantes de um sistema.

Objetos de fronteira
São responsáveis pela comunicação do sistema com os atores. Eles realizam a interface
com atores ou com sistemas externos, além de dispositivos relacionados ao sistema.

Objetos de controle
São responsáveis pela comunicação entre objetos de fronteira e objetos de entidade, co-
ordenando a execução de alguma funcionalidade específica do sistema.

Objetos de entidade
São aqueles que representam todos os conceitos relacionados ao domínio do sistema e
que, posteriormente, na fase de projeto, tornam-se objetos persistentes (que armazenam infor-
mações persistentes no sistema).
As classes de entidade são identificadas na análise de domínio, enquanto as de entidade e
controle são identificadas na análise de aplicação.
Para você identificar classes por meio da técnica de análise dos casos de uso, siga os se-
guintes passos:
a) Observe o comportamento do Caso de Uso para a identificação da classe.
b) Após a identificação da classe, defina suas responsabilidades, seus atributos e associa-
ções (relacionamentos).
c) Faça o refinamento das classes, a fim de retirar inconsistências e redundâncias.
d) Elabore o diagrama de classes.
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 133

12. MODELO DE CLASSES


Para a compreensão da modelagem de classes é necessário que os seus conceitos básicos
estejam sólidos. Por esta razão, até o momento, você conheceu alguns conceitos importan-
tes, tais como: objetos, classes, associação (agregação e composição) e generalização (herança).
Você também deve estar lembrado de que as classes relacionadas por meio de associações
apresentam alguns componentes importantes como: nome do relacionamento, multiplicidade
e papéis.
Os modelos de estrutura são representados, na UML, pelos diagramas de classes e diagra-
mas de objetos. Então, apenas para reforçar um dado importante, a seguir, faremos uma breve
retomada do tema.

Diagrama de classes
O diagrama de classes descreve o aspecto estático do sistema. Mostra as classes e seus
relacionamentos. E, como uma classe descreve grupos de objetos com as mesmas propriedades,
o diagrama de classes descreve os próprios objetos.
Considerado um dos diagramas mais importantes no processo de desenvolvimento de
software, este diagrama modela classes e os relacionamentos e multiplicidades entre elas. Des-
creve a visão estática de um sistema com relação às classes e os relacionamentos entre elas.
No diagrama de classes, as classes são interligadas por meio de relacionamentos. A ligação
mais comum é a de associação, que pode ser mais específica, de acordo com os tipos de objetos
que estão se relacionando. Nesses casos mais especiais temos a agregação e a composição.
Lembre-se que você já estudou este tópico. Em caso de dúvida, volte e examine o conteúdo
apresentado anteriormente. É importante que ele esteja bem assimilado.
As classes de associação são importantes, pois podem ter atributos e operações, como
uma classe comum. No entanto, elas também são associações. Veja o exemplo a seguir.

Figura 13 Exemplo de classe de associação.

No exemplo da Figura 13, a classe Joga é uma classe de associação. O que caracteriza uma
classe de associação é que suas instâncias são originadas das instâncias das classes com as quais

Claretiano - Centro Universitário


134 © Análise e Projeto de Sistemas

ela está relacionada. Uma instância é uma ocorrência. Por exemplo, na classe Jogador, uma
instância para nome do jogador poderia ser "João" (um jogador entre todos aqueles que fazem
parte da classe Jogador). Informações como, por exemplo, o número de gols que um determina-
do jogador fez em um determinado jogo, ou o número de faltas cometidas por um jogador em
um determinado jogo, estão na classe de associação Joga.
Vamos pensar nos atributos para cada uma destas classes. A classe Jogador pode ter os
seguintes atributos: nome do jogador, data de nascimento, RG, CPF, endereço, telefone. A classe
Jogo tem os atributos: local do jogo, data, horário, nome do árbitro, nomes dos times que jogam
esse jogo. E, finalmente, a classe Joga contém informações que não estão nem na classe Joga-
dor, e nem na classe Jogo. Por exemplo, a informação sobre quantos gols determinado jogador
fez em determinado jogo deve ficar armazenada na classe Joga, pois ela não cabe nas demais
classes. Entretanto, ela relaciona as classes Jogador (quem fez os gols) e Jogo (no qual esse jo-
gador jogou e fez os gols).

Diagramas de objetos
Os diagramas de objetos mostram os objetos (instâncias de classes) e seus relacionamen-
tos. Seguindo o exemplo da Figura 13 temos que:

Jogador Pedro:Jogador João:Jogador André:Jogador

Classe Objetos

Figura 14 Classes e objetos.

A Figura 14 mostra a instanciação da classe Jogador, por meio dos objetos Pedro, João e
André.
Na sequência, daremos continuidade ao nosso exemplo, o sistema de vendas da livraria.

13. EXEMPLO: SISTEMA LIVRARIA


Nesta etapa, faremos a construção do modelo conceitual, ou seja, a descoberta inicial das
classes que fazem parte do sistema.
Para isso, é preciso retornar aos Casos de Uso, pois as classes podem ser reconhecidas a
partir deles. Portanto, teremos que retomar o conteúdo estudado na unidade anterior. Você
está lembrado dos Casos de Uso declarados para tirar as informações sobre as classes. Pois bem,
para cada Caso de Uso podemos pensar, inicialmente, nas seguintes classes:
CASOS DE USO CLASSES
1. Manter Dados do Livro Livro
2. Manter Dados do Cliente Cliente
3. Pesquisar Livro Livro
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 135

CASOS DE USO CLASSES


Cliente
Vendedor
Pedido
4. Efetuar Pedido de Compra
ItemDePedido
Produto
Estoque
Cliente
Livro
5. Encomendar Livro
Pedido
ItemDePedido
6. Despachar Livro Pedido
Pedido
7. Pagar à Vista
NotaFiscal
8. Pagar com Cartão de Crédito
Pagamento
9. Pagar com Boleto Bancário
ItemPagamento

Veja, a seguir, como ficará o diagrama de classes na fase inicial.

Figura 15 Diagrama de classes – Sistema Livraria – Vendas.

Você observou, na Figura 15, a primeira visão do diagrama de classes. Lembre-se de que
durante o desenvolvimento, e dependendo da metodologia adotada, pode haver modificações
nos requisitos que, automaticamente, são propagadas pelo sistema, o que provoca modifica-
ções nos artefatos gerados. Por exemplo, o diagrama de classes pode ser modificado pelo acrés-
cimo ou eliminação de classes.
Um detalhe: as pessoas podem enxergar a mesma situação de formas diferentes e consi-
derar que o diagrama de classes deva sofrer alguma modificação. Isso é perfeitamente possível,
pois as pessoas podem ter visões diferentes sobre um mesmo domínio, e apresentarem diferen-
tes soluções para um mesmo problema.

Claretiano - Centro Universitário


136 © Análise e Projeto de Sistemas

A etapa de modelagem da implementação, que será discutida na Unidade 5, mostra que


antes da escrita do código pode ser necessário fazer ajuste de classes, com o objetivo de melhorar
o desenvolvimento do sistema, com tarefas de particionamento ou junção de classes e atributos.
Ainda, é possível pensar em outras classes para completar o referido diagrama. Por exem-
plo, poderíamos ter a classe Editora e Autor. Portanto, não devemos considerar o diagrama
apresentado como um diagrama definitivo, mas que pode ser melhorado.
A seguir, veremos qual a importância do glossário para o sistema da livraria.

Glossário
O glossário é uma espécie de dicionário de termos relacionados ao sistema. É um artefato
importante, pois padroniza os diferentes termos utilizados pelos usuários do sistema, e também
entre o desenvolvedor e o cliente.
Para exemplificar, poderíamos criar um glossário para o sistema de vendas de livros com
os termos descritos no Quadro 2.
Quadro 2 Glossário.
GLOSSÁRIO – SISTEMA LIVRARIA
TERMO SIGNIFICADO
Pedido Refere-se ao conjunto dos itens comprados pelo Cliente.
Refere-se à encomenda de livros realizada pelo Cliente, cuja chegada é aguardada, para a
Pedido em aberto
concretização da venda.
Cliente Pessoa que efetua a compra de livros na livraria.
As pessoas que diretamente trabalharão com o sistema. Por exemplo, o vendedor é um
Usuário usuário. O Cliente da loja também é, quando pesquisa pelo livro desejado no terminal de
pesquisa.

Você acompanhou um pequeno exemplo de como construir um glossário. Vale ressaltar


que não há um formulário padrão para fazê-lo. Você pode usar um quadro, como no exemplo,
uma simples lista ou um formulário mais elaborado. O que importa é que os termos sejam defi-
nidos e esclarecidos para as pessoas envolvidas no sistema.
Uma forma bastante utilizada para glossário é a lista com os termos destacados em negrito,
por exemplo, em ordem alfabética, e o significado de cada um escrito na frente do respectivo ter-
mo.

14. QUESTÕES AUTOAVALIATIVAS


As questões a seguir referem-se aos tópicos estudados nesta unidade, mais especifica-
mente às classes. Responda-as e, caso sinta dificuldade ao realizar as atividades, lembre-se de
rever o conteúdo e discuti-lo com seu tutor e colegas.
1) (POSCOMP – 2008) Na modelagem de classes usando UML (Unified Modeling Language) é sempre recomendável
especificar a multiplicidade dos relacionamentos (associações). Seguindo-se a notação de associação (classe1,
classe2), assinale a alternativa que melhor descreve a multiplicidade da associação Casar (Marido, Esposa).
a) 1:1
b) 1:n
c) n:n
d) 2:1
e) 1:2
© U4 – Processo de Desenvolvimento de Software – Modelagem de Classes 137

2) (POSCOMP – 2008) Os membros de uma classe (atributos e operações) podem ser privados, protegidos ou pú-
blicos em programação orientada a objetos. Suponha agora que se tenha um dado em uma determinada classe
que só deve ser acessado por instâncias dessa mesma classe. Indique a alternativa que melhor descreve o que
este dado pode ser.
a) Somente público.
b) Somente privado.
c) Somente protegido.
d) Privado ou público.
e) Privado ou protegido.
3) (POSCOMP – 2005) Considere as seguintes afirmações sobre o diagrama de classes e outros modelos UML
(Unified Modeling Language):
I. O diagrama de classes pode representar as classes sob diferentes perspectivas, tais como a conceitual, a da
especificação e a da implementação.
II. O diagrama de classes, diferentemente do diagrama de estados, é estático.
III. O diagrama de classes, diferentemente do diagrama de atividades, não contém mensagens.
Quais são as afirmações verdadeiras?
a) Somente a afirmação I.
b) Somente a afirmação II.
c) Somente as afirmações I e III.
d) Somente as afirmações II e III.
e) Afirmações I, II e III.
4) (POSCOMP – 2006) O uso de associações é muito importante em programação orientada a objetos. Considere
agora as afirmações abaixo, relativas ao uso de associações:
I. A multiplicidade de uma associação é uma restrição imposta a essa associação que define o número de
instâncias das classes envolvidas neste relacionamento.
II. A ordenação não é considerada uma restrição a associações, já que ordena as instâncias envolvidas no re-
lacionamento que caracteriza a associação em questão.
III. O uso de papéis só é permitido em associações reflexivas binárias, pois em outros tipos de associações os
papéis causam problemas na modelagem das classes.
Baseado nestas afirmações, escolha a opção correta:
a) As três afirmações são falsas.
b) As três afirmações são verdadeiras.
c) Apenas a afirmação I é verdadeira.
d) As afirmações I e II são verdadeiras.
e) Apenas a afirmação III é verdadeira.
5) (POSCOMP – 2006) Na modelagem de classes usando UML (Unified Modeling Language) é recomendável espe-
cificar a multiplicidade dos relacionamentos (associações). Um tipo muito comum de multiplicidade é a "um-
para-muitos". Nos casos a seguir, aponte qual é o caso que se trata de uma associação "um-para-muitos",
seguindo a notação "associação(classe1, classe2)".
a) Votar (Presidente, Eleitor).
b) Casar (Marido, Esposa).
c) Torcer (Time, Torcedor).
d) Escrever (Livro, Autor).
e) Assinar (Revista, Assinante).

Gabarito
Confira a seguir o gabarito das questões autoavaliativas.
1) a.

2) b.

3) e.

4) c.

5) a.

Claretiano - Centro Universitário


138 © Análise e Projeto de Sistemas

15. CONSIDERAÇÕES
Nesta unidade, você teve a oportunidade de conhecer a fase de desenvolvimento da cons-
trução do modelo conceitual, ou seja, da descoberta das classes que compõem o sistema e os
três estágios pelos quais o modelo de classes passa.
Lembre-se de que os conceitos de classe e objeto são interdependentes, e uma classe é
um conjunto de objetos que compartilham uma estrutura e um comportamento comum, e um
objeto é simplesmente uma instância de uma classe. A UML dispõe do diagrama de objetos, que
apresenta um conjunto de objetos e seus relacionamentos em determinado ponto no tempo.
As classes podem se relacionar entre si por meio de diversos tipos de ligação, tais como
dependência, agregação, composição e herança. Os relacionamentos entre as classes é repre-
sentado por meio do diagrama de classes. Eles são a base das metodologias orientadas a obje-
tos.
Compreendeu também que o modelo de classes é considerado o mais importante dos três
principais modelos da UML (de estados, de interações), pois a partir dele temos a descrição das
informações do sistema.
É importante que você tenha compreendido que o modelo conceitual refere-se às classes
descobertas na fase da análise, daí o nome modelo de classes de análise. Nele estão represen-
tados os conceitos iniciais que se tem do sistema, o que significa que ele é livre de restrições
tecnológicas. Quando chegamos à fase de projeto, para posterior implementação, o modelo de
classes passa a ser chamado de modelo de classes de projeto, o qual deriva do modelo concei-
tual, porém as classes serão implementadas e seus objetos vão interagir entre si na execução de
operações a eles atribuídas.
Convidamos você a refletir sobre as classes de um software. De maneira que garanta cada
estágio da elaboração dos modelos da UML. Pense em estratégias que utilizaria para revisar
seus modelos quanto à clareza, à correção, à completeza e à consistência dos requisitos.
Na próxima unidade você estudará uma nova fase do ciclo de vida de um sistema: a fase
de projeto. Será apresentado o modelo de interações e como é a representação delas entre os
objetos das diferentes classes, em cada processo do sistema, por meio dos diagramas de sequ-
ência e comunicação.

16. REFERÊNCIAS BIBLIOGRÁFICAS


BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.
BOOCH, G. et al. UML: guia do usuário. Rio de Janeiro: Campus, 2000.
FURLAN, J. D. Modelagem de objetos através da UML. São Paulo: Makron Books, 1998.
PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. 3. reimpressão. Rio de Janeiro: Elsevier,
2004.
EAD
Processo de Desenvolvimento
de Software – Modelagem de
Interações
5

1. OBJETIVOS
• Obter uma visão geral da fase de projeto.
• Compreender o modelo de interações.

2. CONTEÚDOS
• Visão geral da fase de projeto.
• Atividades desenvolvidas na fase de projeto.
• Modelo de interações.
• Diagrama de Sequência.
• Diagrama de Comunicação.

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a seguir:
1) Nesta unidade você verá a transição da fase de análise para a fase de projeto do de-
senvolvimento de software. Essa transição é quase imperceptível, pois ela ocorre aos
poucos e naturalmente, devido à evolução dos modelos e do próprio desenvolvimen-
to do software. Dessa forma, certifique-se de que compreendeu bem o modelo con-
ceitual, pois é dele que surge o modelo de classes de projeto.
2) O modelo de classes é utilizado para representar a estrutura das classes do sistema
tanto na fase de análise, como na fase de projeto. Reveja, antes de iniciar o estudo
desta unidade, todos os elementos que compõem o modelo de classes de análise.
140 © Análise e Projeto de Sistemas

3) Em muitos momentos, análise e projeto podem estar ocorrendo ao mesmo tempo.


Assim, assegure-se de ter compreendido todo o processo de desenvolvimento, des-
de o princípio. Lembre-se que o modelo de classes de projeto é derivado do modelo
conceitual de classes. E, o modelo conceitual de classes, juntamente com o modelo de
casos de uso, são artefatos construídos na fase de análise.
4) Certifique-se de ter compreendido como identificar as classes de um sistema de
software orientado a objetos. Agora sua preocupação será em como refinar essas
classes.
5) Sua formação é essencial, pois ela determinará posturas e escolhas no desenvolvimen-
to de sua prática. Invista em você, faça da pesquisa e da interação com seus colegas de
curso hábitos que poderão ajudá-lo a ampliar e a aprofundar seus conhecimentos.
6) Você pode buscar em sites da internet maiores informações sobre a Interação Huma-
no-Computador (IHC). Para os desenvolvedores de software, é bastante interessan-
te conhecer outros fatores que influenciam na qualidade do sistema desenvolvido,
como, por exemplo, a usabilidade.
7) Se você ainda tiver dúvidas sobre Casos de Uso, volte e reveja o conteúdo estudado
anteriormente. Os Casos de Uso são a base para o desenvolvimento da modelagem de
sistemas orientados a objetos.
8) Adquira o hábito da leitura e da pesquisa. Leia livros, revistas e periódicos, pesquise
em sites. Caso encontre alguma novidade relacionada ao conteúdo estudado, com-
partilhe com seus colegas de curso.

4. INTRODUÇÃO À UNIDADE
Na unidade anterior, você teve a oportunidade de aprender as atividades que acontecem
na fase de análise do desenvolvimento de sistemas.
Nesta unidade, você verá a transição da fase de análise para a fase de projeto, com as ati-
vidades de desenvolvimento que nela ocorrem.
E, ao final da unidade, daremos continuidade a mais uma etapa do desenvolvimento do
Sistema Livraria, em que será abordado o modelo de interações.

5. DA ANÁLISE AO PROJETO
A transição da fase de análise para a fase de projeto não é altamente perceptível, pois as
tarefas em ambas as fases chegam a se confundir. A mudança de uma fase para a outra acon-
tece de acordo com a evolução do desenvolvimento. Um exemplo disso é o modelo de classes
que é utilizado em ambas as fases, na representação da estrutura das classes que compõem o
sistema.
Apenas relembrando, a fase da análise preocupa-se com o "o que" será feito pelo novo
sistema, enquanto a fase de projeto trata do "como" fazer. A análise propicia um entendimento
completo sobre o novo sistema, especialmente com a criação do diagrama de classes de análise.
Essas classes serão transportadas para o projeto e serão refinadas, ou seja, receberão detalhes
para permitir que decisões mais específicas em relação ao novo sistema possam ser tomadas.
Na fase de análise foram gerados dois artefatos importantes: o modelo de Casos de Uso e o
modelo de classes de análise (fronteira, controle e entidade). Agora, na fase de projeto, o que se
deseja é o refinamento das classes de análise.
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 141

Para demonstrar esta fase, o modelo de interações descreve como ocorrem as interações
entre os objetos (comportamento), ou seja, ele representa a troca de mensagens entre os obje-
tos, que ocorre na execução dos Casos de Uso. As interações podem ser modeladas por meio de
Casos de Uso, diagramas de sequência ou, ainda, pelos diagramas de atividades, dependendo
do nível de abstração. Cada um deles representa aspectos diferentes das interações.
O modelo de interações tem seu início na fase de análise, com a criação do modelo de Casos
de Uso. A partir dos Casos de Uso é possível descobrir os conceitos, também conhecidos como
objetos, que fazem parte do sistema. Dessa forma, começa a ser criado o modelo conceitual de
classes. Entretanto, o artefato produzido não contempla informações suficientes para o início da
fase de implementação. Daí a necessidade de continuar, na fase de projeto, sua construção.

6. ATIVIDADES REALIZADAS NA FASE DE PROJETO


Segundo Blaha e Rumbaugh (2006), a fase de projeto tem dois estágios: projeto de siste-
mas e projeto de classes.
O projeto de sistemas está relacionado com os aspectos da arquitetura para resolver o
problema da aplicação, e o projeto de classes aprimora e ajusta os modelos do mundo real,
gerados na fase de análise, preparando-os para a implementação.
Conforme explica Bezerra (2007), as atividades realizadas nos dois estágios da fase de pro-
jeto podem ser detalhadas das seguintes formas:

Detalhamento dos aspectos dinâmicos


Refere-se à construção dos modelos de interações, estados e atividades (modelagem di-
nâmica do sistema).

Refinamento dos aspectos estáticos e estruturais


Refere-se ao refinamento dos aspectos estático e estrutural das classes de análise, por
meio da especificação de atributos, operações e associações das classes do sistema (classes de
projeto).

Projeto de arquitetura
O projeto de arquitetura refere-se às diferentes atividades de desenvolvimento relaciona-
das ao sistema, tais como a definição da decomposição (subsistemas) e distribuição física dos
componentes pelos diversos equipamentos, definição das interfaces, reutilização de componen-
tes, entre outras.

Persistência de objetos
Esta atividade preocupa-se em como manter as informações do sistema, considerando
fatores como o controle de transações, os mecanismos de armazenamento e o mapeamento de
objetos para o modelo relacional.

Projeto de interface gráfica com o usuário


As atividades de interface gráfica com o usuário estão relacionadas com a forma que o
usuário tem para interagir com o sistema. Nesta etapa, devem ser considerados os aspectos de
usabilidade, além de outros discutidos na Interação Humano-Computador (IHC).

Claretiano - Centro Universitário


142 © Análise e Projeto de Sistemas

Projeto de algoritmos
A atividade de projeto de algoritmos preocupa-se, ainda, com a escolha dos algoritmos
a serem utilizados na implementação. Para isso, são considerados fatores como a facilidade de
compreensão do problema e sua complexidade computacional. A UML dispõe do diagrama de
atividades que é usado para colaborar nesta etapa do desenvolvimento.

7. O QUE FOI PRODUZIDO ATÉ O MOMENTO


Este é um momento de extrema importância para o projeto de um sistema de software.
Trata-se de uma fase de transição. Na fase da análise, o objetivo é o de se buscar uma solução
para o problema proposto. Todas as técnicas aplicadas, especialmente o uso da UML para ela-
borar os diagramas, colaboram para que tal objetivo seja atingido. Não há preocupação com as
restrições tecnológicas, mas apenas com a definição de uma solução para o problema.
É uma fase em que o sucesso do sistema depende, em quase sua totalidade, de um levan-
tamento de requisitos bem elaborado, de forma que a compreensão do sistema fique clara para
os desenvolvedores e estes, por sua vez, consigam transmitir ao cliente o que será produzido
para atender às suas solicitações.
A fase de análise produziu, até aqui:
• O modelo conceitual, também conhecido por modelo de classes de análise, que repre-
senta de forma estática a informação a ser gerenciada pelo sistema.
• O modelo de Casos de Uso, que mostra como os usuários trocam informações com o
sistema. Lembramos que este modelo não revela como a informação é processada in-
ternamente no sistema.
Por meio dos Casos de Uso é possível identificar as operações e as consultas do sistema. As
operações referem-se à entrada de informações no sistema e, as consultas, ao acesso a informa-
ções que estão armazenadas nele. O modelo de casos de uso descreve os requisitos funcionais
do sistema e os atores que interagem com ele. É possível saber as ações do sistema conforme os
atores as percebem. Entretanto, nada temos de informação sobre o comportamento interno do
sistema ou sobre como determinada funcionalidade vai se realizar.
Podemos observar que os dois modelos gerados se completam, pois sozinhos, nenhum
deles carrega informações completas sobre o sistema.
Segundo Bezerra (2007), o modelo de Casos de Uso não responde sobre:
• Quais operações devem ser executadas pelo sistema;
• A que classes as operações pertencem;
• Quais objetos participam da realização de determinado caso de uso.
O modelo conceitual ou modelo de classes de análise fornece uma visão estrutural do
sistema, por isso mesmo é chamado de visão estática. Ele gera as classes, mas também não res-
ponde a algumas questões sobre:
a) A forma como os objetos colaboram para que determinado Caso de Uso seja realiza-
do;
b) A ordem em que as mensagens são enviadas durante a realização dos casos de uso;
c) As informações que são trocadas pelos objetos;
d) Possíveis responsabilidades ou classes que ainda não foram descobertas.
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 143

O modelo de interações surge com o propósito de responder às questões que os dois


modelos (classes e Casos de Uso) não conseguem. Ele representa as mensagens que os objetos
trocam entre si, para a execução de cenários dos casos de uso do sistema. Permite, ainda, o re-
finamento do modelo de classes, com a identificação das operações e atributos das classes que
compõem o modelo de classes.
Os diagramas de interação ajudam na compreensão dos aspectos dinâmicos do sistema de
software, além de colaborarem, também, a documentar estes aspectos. Descrevem a sequência
das mensagens trocadas entre os objetos que participam de um Caso de Uso, esclarecendo, in-
clusive, características dos Casos de Uso, tais como o controle de execução e a concorrência no
envio de mensagens.

8. OS MODELOS QUE COMPÕEM A MODELAGEM DE INTERAÇÕES


Vimos, anteriormente, que a modelagem de interações pode variar em função do nível de
abstração que se estiver considerando.
Assim, os Casos de Uso são considerados no nível mais alto de abstração, pois eles repre-
sentam as funcionalidades do sistema e revelam como os atores interagem com ele.
A notação gráfica da UML para a representação dos Casos de Uso é o diagrama de Casos
de Uso, que reúne todos os Casos de Uso que descrevem a funcionalidade completa do sistema,
com todos os atores que, de alguma maneira, trocam informações com o sistema.
Dessa forma, a UML dispõe de diagramas utilizados na modelagem de interações, deno-
minados diagramas de interação. São eles: diagrama de sequência e diagrama de comunicação.
Antes da versão 2.0, ou seja, nas versões 1.X da UML, dois diagramas eram utilizados na cons-
trução do modelo de interações: o diagrama de sequência e o diagrama de comunicação (que
na versão 1.X era conhecido como diagrama de colaboração). Na versão 2.0 da UML há mais
um diagrama de interação, conhecido por diagrama de visão geral de interação. Ele apresenta
uma visão das diversas interações entre objetos, ou seja, uma visão dos diversos cenários de um
Caso de Uso.
Tanto o diagrama de sequência como o de comunicação representam as mensagens troca-
das entre os objetos. O que difere um do outro é o foco das interações, ou seja, nos diagramas
de sequência o foco está na forma como as mensagens são trocadas no decorrer do tempo,
enquanto nos diagramas de comunicação o foco está nos relacionamentos existentes entre os
objetos. Entretanto, o diagrama de sequência é mais utilizado que o diagrama de comunicação.
E, ainda, um diagrama de comunicação pode ser transformado em um diagrama de sequência
e, um diagrama de sequência pode ser transformado em um diagrama de comunicação. Isso se
deve ao fato de que os dois são equivalentes entre si.
Segundo Bezerra (2007, p. 182), realização de um Caso de Uso é o termo usado para de-
signar "a interação entre objetos para dar suporte à funcionalidade de um caso de uso". Ela
descreve o comportamento de um ponto de vista interno ao sistema. Os diagramas de interação
representam a realização de um Caso de Uso.
Os diagramas de sequência são derivados dos Casos de Uso e um caso de uso pode origi-
nar um ou mais diagramas de sequência. Você está lembrado de que os Casos de Uso têm um
fluxo principal e os fluxos de exceção, e para cada cenário de um caso de uso podemos ter um
diagrama de sequência. Observe que, nos diagramas apresentados nesta unidade, apenas o
cenário relacionado ao fluxo principal do caso de uso está representado. Este tipo de represen-

Claretiano - Centro Universitário


144 © Análise e Projeto de Sistemas

tação é o mais comum de ser encontrado. Eles ilustram a sequência das execuções e interações
entre os objetos, além de mostrarem a sequência das ações a serem executadas pelo software
quando um ator interage com ele.

9. OS ELEMENTOS QUE COMPÕEM A MODELAGEM DE INTERAÇÕES


Diversos componentes do modelo de interação são comuns a ambos os diagramas: sequ-
ência e comunicação.
A seguir, a apresentação desses elementos:

Mensagem
Considerada como o elemento mais importante, além de ser o princípio básico da inte-
ração entre objetos. Segundo Bezerra (2007, p. 185), "uma mensagem representa a requisição
de um objeto remetente a um objeto receptor para que este último execute alguma operação
definida para sua classe". A mensagem enviada pelo objeto remetente deve conter informação
suficiente para que a operação do objeto receptor seja executada.
Quando um objeto remetente envia uma mensagem, esta invoca a execução de uma ope-
ração do objeto receptor. Uma operação é uma rotina de programação implementada em algu-
ma linguagem, e definida dentro de uma classe. Portanto, uma mensagem nada mais é do que
informações que são passadas a uma operação a ser executada no objeto receptor.
Quanto à sua natureza, uma mensagem pode ser dos seguintes tipos:

a) Síncrona: quando o objeto remetente espera que o objeto receptor processe as infor-
mações carregadas na mensagem, antes de recomeçar o seu processamento.
b) Assíncrona: quando o objeto remetente não espera a resposta para continuar o pro-
cessamento.
c) De sinal: mensagem usada para enviar um sinal (conceito utilizado quando se trata,
por exemplo, de sistemas distribuídos – uma requisição entre dois módulos).
d) De retorno: utilizada para especificar o fim de uma mensagem enviada anteriormen-
te.
e) Reflexiva: quando um objeto requisita a execução de uma operação definida em sua
própria classe.
Utilize as mensagens de retorno quando o resultado de uma mensagem não ficar claro
e objetivo para quem estiver lendo o diagrama de sequência. Quando em um diagrama de se-
quência houver muitos objetos colaborando, muitas mensagens de retorno podem confundir o
leitor, pois pode deixar o diagrama poluído.
A sintaxe da UML utilizada para as mensagens é:
[[expressão-sequência] controle:] [variável :=] nome [(argumentos)], em que:
a) expressão-sequência: refere-se à uma expressão à qual uma mensagem pode estar
associada. Por exemplo, se duas mensagens possuem expressão de sequência, ao se-
rem enviadas é possível conhecer a ordem em que elas foram enviadas.
b) controle: – cláusula-condição: significa que uma mensagem apenas será enviada se
o valor da expressão lógica for verdadeiro. Por exemplo: supondo-se que [x > y] seja
uma cláusula de condição, a mensagem somente será enviada se x for maior que y. A
cláusula-condição também é conhecida por condição de guarda. Usada entre colche-
tes. O outro tipo de controle é conhecido como cláusula-iteração, e representa uma
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 145

repetição do envio de uma mensagem. Sua representação é acompanhada de um * no


início da expressão. Por exemplo: *[para i:=1..100], significa que a mensagem relacio-
nada a este controle será enviada 100 vezes.
c) variável: corresponde à variável que recebe o valor retornado pela operação executa-
da no objeto receptor.
d) nome: corresponde à expressão de chamada de uma operação definida na classe do
objeto receptor.
e) argumentos: refere-se à uma lista de argumentos (que pode ou não existir) e, quando
existe, é utilizada junto ao nome.
Uma mensagem pode ter um mínimo de componentes, no caso de conter apenas o seu
nome. Por exemplo:
1: comprarProduto(item)
E, oposto a isso, pode conter todos os elementos da sintaxe. Os elementos definidos entre
colchetes são opcionais.
*[i := 1..100]: parcelas[i].somar( )

10. DIAGRAMA DE SEQUÊNCIA


Ilustra uma interação de acordo com uma visão temporal. É representado por uma dimen-
são horizontal, mostrando o conjunto de objetos que interagem entre si pela troca de mensa-
gens, assim também como os atores envolvidos nos Casos de Uso realizados. E, uma dimensão
vertical, que representa o tempo.
Seu objetivo é o de apresentar as interações entre os objetos na ordem em que elas acon-
tecem no tempo. Ele exibe, visualmente, a sequência das ações que o software vai executar, de
acordo com os comandos fornecidos por um ator.
A elaboração de um diagrama de sequência é embasada nos diagramas de Casos de Uso
e de classes, e ele permite:
• Definir corretamente as regras de negócio;
• Refinar o diagrama de classes;
• Mostrar a sequência das execuções e interações entre objetos.
Assim, podemos entender que o diagrama de sequência é elaborado com foco nos requi-
sitos, assim como na implementação do sistema.

Considerações para a construção dos diagramas de sequência


A seguir, algumas considerações para a construção do diagrama de sequência. São elas:
a) Ter o diagrama de classes das classes que será utilizado no desenvolvimento do siste-
ma.
b) Construir o diagrama de sequência de forma simples e objetiva. Evitar a poluição com
informações descritivas. Caso haja necessidade de algum tipo de informação adicional
ou mais detalhada, colocar em uma documentação à parte.
c) O diagrama de sequência deve ilustrar as ações que ocorrem em um cenário na linha
de tempo, iniciadas por um ator.
d) Observar que os relacionamentos entre as classes (no diagrama de classes) vão de-
terminar as trocas de informações (ou interações) entre os objetos correspondentes
a essas classes.

Claretiano - Centro Universitário


146 © Análise e Projeto de Sistemas

e) Observar, também, os Casos de Uso que fazem parte do diagrama de casos de uso, e
associar cada um às classes pertencentes aos relacionamentos identificados.

Etapas para a construção de um diagrama de sequência


A seguir, as etapas para a construção do diagrama de sequência. São elas:
1) Identificação de um cenário, por meio da análise da especificação e do diagrama de
Casos de Uso.
a) Pelo diagrama de classes de análise, verificar os relacionamentos entre as clas-
ses.
b) Identificar os métodos das classes que se relacionam.
c) Pelo diagrama de classes, identificar os parâmetros utilizados na execução dos
métodos de cada classe.
d) Por meio do diagrama de classes, identificar o tipo de retorno do método chama-
do no diagrama de sequência.
2) A partir da versão 2 da UML é possível a construção de mais de um cenário em um
único diagrama de sequência.
A seguir, a Figura 1 ilustra o Diagrama de Sequência.

Figura 1 Diagrama de Sequência – Pesquisar Livro.

Como já vimos anteriormente, o Diagrama de Sequência enfatiza a ordenação sequencial


em que os comportamentos acontecem. Além dos objetos e dos atores, outros elementos apre-
sentados neste diagrama também são essenciais, tais como:
a) Linha de vida: as linhas verticais nos Diagramas de Sequência são chamadas de linha
de vida, elas representam a vida do objeto durante uma interação. Cada objeto repre-
sentado tem sua linha de vida independente.
b) Foco de controle: representa o período de duração da colaboração entre os objetos.
c) Mensagens: a mensagem é representada por uma seta horizontal entre dois objetos,
ou melhor, entre as linhas de vida dos objetos, e sua ordem é mostrada de cima para
baixo no diagrama. Cada mensagem deve ser rotulada, ou seja, deve possuir um iden-
tificador.
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 147

As mensagens em um diagrama de sequência podem ser de quatro tipos:


• Síncronas.
• Assíncronas.
• Recursivas.
• De retorno.
As mensagens síncronas são representadas por uma linha contínua, com uma seta na pon-
ta, conforme mostra a Figura 2. São chamadas para as quais se espera um retorno imediato. Isso
significa que estas chamadas sempre retornam alguma resposta para a classe a qual o método
foi invocado.

Figura 2 Mensagem síncrona.

As mensagens assíncronas são aquelas para as quais se espera um retorno, porém esse
retorno não é imediato. Sua representação é uma meia-seta e pode ser vista na Figura 3.

Figura 3 Mensagem assíncrona.

As mensagens recursivas, também conhecidas por autochamadas, são aquelas que acon-
tecem quando uma classe chama um método contido nela mesma. Sua representação pode ser
vista na Figura 4.

nomeClasse

nomeDoMetodo( )

Figura 4 Mensagem recursiva (autochamada).

As mensagens de retorno representam o retorno à classe para a qual foi realizada a cha-
mada. Sua representação é uma linha tracejada com uma seta na ponta, e pode ser vista na
Figura 5.

Figura 5 Mensagem de retorno.

Nos diagramas de sequência, a passagem do tempo é representada de cima para baixo,


ou seja, quanto mais abaixo uma mensagem aparecer, significa que tanto mais tarde esta men-
sagem foi enviada.
a) Condição: indica quando uma mensagem é enviada a um objeto, desde que esta con-
dição seja verdadeira.
b) Marcador de interação (ou de controle): o marcador de interação demonstra quantas
vezes uma mensagem é enviada a um objeto.

Claretiano - Centro Universitário


148 © Análise e Projeto de Sistemas

c) Raias de natação: são utilizadas para organizar as atividades representadas em dia-


gramas. Nas raias de natação criamos grupos que são responsáveis pelas atividades
que ocorrem nos Diagramas de Atividades e então, separamos esses grupos por meio
de linhas delimitadoras, o que lembra uma piscina vista de cima, daí o nome raias de
natação.
d) Ocorrências de execução: são representadas por blocos retangulares que ficam sobre
a linha de vida de um objeto. Esses blocos representam o tempo em que um objeto
se mantém ativo enquanto realiza uma operação. No objeto receptor, o topo de uma
ocorrência coincide com o recebimento de uma mensagem. E, a parte de baixo da
ocorrência coincide com o término de uma operação que o objeto realizou.
e) Criação de objetos: significa o momento em que o objeto passa a existir no sistema.
Um objeto pode existir desde o início no sistema. Quando isso ocorre, ele fica posi-
cionado no topo do diagrama. Todavia, se o objeto for criado posteriormente, ele é
representado por um retângulo, que fica numa posição mais abaixo que os demais
objetos. A posição na qual ele fica no diagrama indica o momento em que o objeto
é criado (ou instanciado). É a partir desse momento que ele começa a interagir. A
criação de um objeto é requisitada por outro, que também participa da interação por
meio de uma mensagem. Normalmente, a instanciação de um objeto no diagrama de
sequência é representada por meio de um estereótipo: <<create>>. A seta que indica
o sentido da criação do novo objeto é pontilhada, e aponta para o objeto, e não para
a linha de vida, como nos demais objetos.

Figura 6 Estereótipo <<create>> na criação de objetos.

f) Destruição de objetos: ocorre quando o objeto não é mais necessário na interação.


A destruição do objeto é representada, no diagrama de sequência, pelo símbolo X na
parte de baixo da linha de vida. A mensagem de destruição é representada pelo este-
reótipo <<destroy>>. Veja a representação desse estereótipo na Figura 7.
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 149

Figura 7 Estereótipo <<destroy>> na destruição de objetos.

Veja na Figura 8 os elementos gráficos representados:

Objeto1 Objeto2 Objeto3

Mensagem

Foco de Auto-chamada
controle
do * [condição]
objeto 1
Mensagem de retorno Mensagem3

Linha de vida
do objeto 1

Figura 8 Representação dos elementos gráficos de um Diagrama de Sequência.

Exemplificamos, graficamente, um Diagrama de Sequência para exclusão de usuários para


o Sistema Gerenciador de Avaliações.

Claretiano - Centro Universitário


150 © Análise e Projeto de Sistemas

Figura 9 Diagrama de Sequência para exclusão de usuários.

11. DIAGRAMA DE COMUNICAÇÃO


Agora que você já estudou os diagramas de sequência, veremos os diagramas de comuni-
cação.
Assim como os diagramas de sequência, os diagramas de comunicação também derivam
dos Casos de Uso, e têm o mesmo objetivo do Diagrama de Sequência.
Isso significa que eles representam os aspectos comportamentais do sistema, e fornecem
informações sobre como as interações são efetuadas entre os objetos, ou seja, quais são os
objetos e de que forma eles executam suas participações nas interações. Mostram os objetos
envolvidos na realização de um caso de uso, e as ligações entre eles.
As mensagens entre os objetos, tal qual nos diagramas de sequência, também são mos-
tradas. A diferença entre os diagramas de sequência e os diagramas de comunicação está na
posição das mensagens. Nos diagramas de comunicação não é possível saber a ordem em que
elas são enviadas, a não ser pela observação da numeração que acompanha as mensagens.
Os diagramas de comunicação não representam o tempo como uma dimensão separada.
As operações executadas são representadas em um conjunto, independentemente do tempo de
execução de cada uma.
Outra diferença está na ordem das chamadas, que não é modelada no diagrama de comu-
nicação. O que interessa nesse diagrama é apenas a forma como os objetos colaboram entre si
para que uma finalidade seja executada com sucesso.
As ligações são elementos particulares dos diagramas de comunicação e correspondem a rela-
cionamentos entre os objetos. Graficamente, são representadas por linhas que ligam os objetos.
Ainda, quanto à leitura do diagrama, a ordem de leitura do envio de mensagens é diferen-
te nos dois diagramas. Enquanto no diagrama de sequência a ordem de leitura das mensagens é
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 151

determinada por sua posição vertical no diagrama (supondo-se que mensagem mais ao topo do
diagrama tenha sido a primeira a ser enviada), no diagrama de comunicação somente é possível
saber a ordem de envio das mensagens por meio das expressões de sequência.
Quanto aos componentes do diagrama de comunicação, lembramos que o rótulo de uma
mensagem pode mostrar um elemento de controle, e o sentido da mensagem é indicado por
uma seta que fica próxima ao rótulo da mensagem.
Um exemplo de diagrama de comunicação pode ser visto na Figura 10.

Figura 10 Diagrama de Comunicação usando condição de guarda.

Em que:
1: representa a sequência da ordem de envio da mensagem.
[x > 0]: representa a condição de guarda (ou guarda).
Message3: representa a mensagem enviada do objeto da Classe1 (remetente) para o ob-
jeto da Classe2 (receptor).
( ): representa a lista de argumentos (neste exemplo está vazia).
Considerações para a construção dos diagramas de comunicação
• É necessário que o diagrama de classes já esteja elaborado, pois ele fornece informa-
ções sobre os relacionamentos entre as classes do sistema.
• É necessário que o diagrama de sequência esteja elaborado, pois ele fornece informa-
ções sobre os fluxos de mensagens entre os objetos.
Etapas para a construção de um diagrama de comunicação
a) Pelo diagrama de sequência, verificar as classes que efetuam interações entre si.
b) Com base no diagrama de sequência, nomear os objetos e identificar suas classes.
c) Inserir as mensagens realizadas entre os objetos.
d) Tornar o diagrama legível e permitir a compreensão das colaborações efetuadas entre
os objetos, inserindo numeração nas chamadas.
Veja, na Figura 11, como fica o diagrama de comunicação para a mesma pesquisa de livro,
mostrada no diagrama de sequência da Figura 1.

Claretiano - Centro Universitário


152 © Análise e Projeto de Sistemas

Figura 11 Diagrama de Comunicação – Pesquisar Livro.

Como você viu anteriormente, o Diagrama de Colaboração/Comunicação é o segundo tipo


de Diagrama de Interação. Ele enfatiza a ordem estrutural dos objetos que colaboram entre si.
O Diagrama de Colaboração/Comunicação pode ser visto como um Diagrama de Sequên-
cia simples, que não utiliza elementos como interações ou fragmentos combinados. Este diagra-
ma é utilizado quando o foco do estudo for modelar a interação entre os objetos, mas não sua
sequência de mensagens.
Como a disposição dos objetos é estrutural e não linear, o sequenciamento das mensagens
é determinado por uma sucessão numerada, indicando a ordem e, se for o caso, o alinhamento
do processamento. A forma de numeração mais usual é 1, 1.n, 1.n.n, 2 etc.
As mensagens, neste diagrama, são semelhantes às do Diagrama de Sequência.
Na Figura 12, vamos observar o exemplo de um Diagrama de Colaboração/Comunicação
para visualização de prova do Sistema Gerenciador de Avaliações.

1: Acessar tela professores()

Figura 12 Diagrama de Colaboração/Comunicação para visualização de prova.


© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 153

12. CONSTRUÇÃO MODULAR DE DIAGRAMAS DE INTERAÇÃO


A UML, a partir da versão 2.0, ampliou o conjunto de elementos gráficos para a construção
dos diagramas de interação. Estes novos elementos são compostos por quadros de interação,
fragmentos combinados, referências, operadores, entre outros.
Neste tópico, apresentaremos alguns destes elementos.

Quadros de interação

Sua função é a de encapsular um diagrama de sequência. Pode ser entendido como uma
fronteira, dentro da qual podem ser colocados os elementos de um diagrama de sequência. Re-
presentado por um retângulo, conforme mostra a Figura 13.

Figura 13 Notação para um quadro na UML.

Qualquer diagrama de interação pode ser acomodado no interior de um quadro. Note, no


rótulo do quadro, que é possível colocar o nome do diagrama neste lugar. As letras sd indicam
tratar-se da modularização de um diagrama de sequência. No entanto, é possível que os diagra-
mas a serem modulados sejam um diagrama de comunicação (comm), ou activity (diagrama de
atividades). Este é o primeiro objetivo para se construir um diagrama em um quadro.
O segundo objetivo para que o modelador do sistema utilize o rótulo do quadro, é para
fazer referência a um diagrama definido separadamente, indicando que ele corresponde a uma
ocorrência de interação (uma interação referenciada por outra). Pense que uma interação seja
comum a vários diagramas de sequência. Neste caso, essa ocorrência fica rotulada em um qua-
dro, de forma que ele possa ser reutilizado diversas vezes. No rótulo deste quadro deve aparecer
a palavra ref.
O terceiro objetivo para se trabalhar com quadros é para definir o controle da interação.
Para isso, a UML define um outro tipo de quadro, chamado de fragmento combinado. Com ele,
o modelador pode definir o fluxo de controle nos diagramas de interação.
Um fragmento combinado recebe este nome porque é formado por um ou mais operan-
dos (sequência de mensagens) da interação, zero ou mais condições de guarda e um operador
de interação (alt, opt, loop, entre outros).
• alt: para modelar construções do tipo se-então-senão.
• opt: similar ao alt, também modela construção procedimental do tipo se...então, com
a diferença de que está associado a apenas um operando.
• loop: para modelar interações que devem ser realizadas zero ou mais vezes.
Claretiano - Centro Universitário
154 © Análise e Projeto de Sistemas

13. CONSIDERAÇÕES PARA A CONSTRUÇÃO DO MODELO DE INTERAÇÕES


Vimos, nesta unidade, algumas considerações gerais para a construção dos diagramas de
sequência e de comunicação. Consideremos, agora, alguns aspectos específicos para a constru-
ção do modelo de interações.
As mensagens são trocadas entre os objetos a fim de que eles cumpram suas responsabili-
dades. Um objeto precisa enviar mensagens a outros objetos. Ainda, quando uma mensagem é
enviada, significa que existe uma operação no objeto receptor, que será executada por ocasião
do envio da mensagem. Portanto, ao modelarmos um diagrama de sequência estamos especi-
ficando quais mensagens serão enviadas de um objeto a outro, e as operações que as classes
devem ter. E, a definição de uma mensagem no modelo de interações, significa atribuição de
responsabilidade a uma classe.
Existem dois princípios considerados fundamentais para a construção do modelo de inte-
rações. São eles: coesão e acoplamento.
Estes dois princípios servem como orientadores no momento da identificação das classes
e de alocação de responsabilidades. Para a realização dessa tarefa, é muito importante a experi-
ência do modelador e o conhecimento de princípios básicos de desenvolvimento de software.
Vejamos, agora, o que são os princípios de coesão e acoplamento, e como eles servem
como orientação no momento de identificação das classes.
• Coesão: trata-se de uma medida capaz de mostrar o quão fortemente as responsabi-
lidades de uma classe estão relacionadas. Isso significa que, ao definir as classes, isso
deve ser feito de maneira que cada uma delas tenha alta coesão. Classes com baixa
coesão são sinônimos de vários problemas. Elas são menos reutilizáveis, são mais com-
plexas, menos inteligíveis e de manutenção mais complicada. Para compreender o que
é coesão, neste caso, pense que uma classe possa apresentar dois ou mais grupos de
atributos ou operações, em que cada um destes grupos estão com seus elementos for-
temente relacionados entre si, porém, entre os grupos há um baixo grau de correlação.
A melhor solução, neste caso, seria ter mais de uma classe, cada qual com seu grupo de
atributos ou operações fortemente correlacionados entre si.
• Acoplamento: trata-se de uma medida capaz de mostrar o quão fortemente uma classe
está conectada a outras classes, tem conhecimento de outras classes ou depende delas.
Uma classe com baixo acoplamento é mais independente de outras classes. Quando o
acoplamento é alto, significa que as classes são menos inteligíveis, menos reutilizáveis
e, também, mais sensíveis a mudanças.
Assim, em se tratando dos princípios de coesão e acoplamento para o desenvolvimento de
sistemas, é desejável que os modelos criados apresentem alta coesão e baixo acoplamento.
Para a construção do modelo de interações, os seguintes procedimentos devem ser con-
siderados:
a) Identificação das classes que compõem o modelo conceitual, ou seja, que fazem parte
dos casos de uso.
b) Identificação das classes de software que possam auxiliar na organização das tarefas
a serem executadas.
c) Definição de objetos que criam outros objetos.
d) Certificar-se de que cada cenário relevante para cada caso de uso foi considerado
na modelagem de interações. Considerar, ainda, que na construção do diagrama de
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 155

interação, novas classes podem ser descobertas, assim como atributos, operações e
associações.
e) Construir diagramas de interação o mais inteligíveis possível.
Segundo Bezerra (2007), os passos para a construção dos diagramas de interação são:

1) Selecionar um conjunto de cenários relevantes para cada caso de uso.


2) Para cada cenário selecionado, faça:
a) Coloque no diagrama o ator, o objeto de fronteira e o objeto de controle;
b) Para cada cenário, defina as mensagens que serão trocadas entre os objetos;
c) Se for o caso, defina as cláusulas de condição e iteração para as mensagens;
d) Acrescente ao cenário selecionado outros objetos, se isso se fizer necessário.
A seguir, daremos continuidade ao exemplo do Sistema da Livraria.

14. EXEMPLO: SISTEMA LIVRARIA


Nesta etapa do sistema de vendas de livros, vamos mostrar os diagramas de sequência
para os dois Casos de Uso descritos: Efetuar Pedido de Compra e Encomendar Livro.
Acompanhe, na Figura 14, a apresentação do diagrama de sequência para Efetuar Pedido
de Compra.

Figura 14 Diagrama de Sequência – Efetuar Pedido de Compra.

Um diagrama de sequência mostra, na primeira linha, as classes cujos objetos são respon-
sáveis pelas trocas de mensagens. Cada seta indica a origem e o destino de uma mensagem.
Note, também, as setas tracejadas. Elas correspondem ao retorno das mensagens.
O exemplo da Figura 14 trata da representação das sequências de operações que ocorrem
no cenário principal do caso de uso Efetuar Pedido de Compra. Vamos acompanhar o início deste
diagrama para entender o seu significado.

Claretiano - Centro Universitário


156 © Análise e Projeto de Sistemas

O vendedor informa o título do livro ao sistema. Note que uma classe de fronteira recebe
a entrada. Em seguida, a representação indica que, de posse do título do livro, é possível buscar
este título no estoque da loja. Como estamos trabalhando no cenário principal, o livro será en-
contrado, ou seja, estará disponível para compra. Essa resposta é mostrada pela seta de retorno.
Veja que não há necessidade de uma mensagem acompanhando esta seta, pois seu conteúdo é
perfeitamente compreendido por quem estiver lendo o digrama.

Figura 15 Diagrama de Sequência – Encomendar Livro.

A Figura 15 mostra o diagrama de sequência do cenário principal do caso de uso Encomen-


dar Livro.

15. QUESTÕES AUTOAVALIATIVAS


Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:
1) Em relação aos diagramas de sequência, é correto afirmar que:
a) Representam as interações entre atores e objetos do sistema.
b) Representam os fluxos de atividades entre as classes e os diferentes cenários.
c) Representam as interações entre as classes e os objetos do sistema.
d) Representam a ordem temporal das classes e objetos do sistema.
e) Representam as interações entre as classes e atributos do sistema.
2) Estão corretas as seguintes etapas correspondentes à elaboração de um diagrama de sequência, exceto:
a) Verificação das classes que se relacionam e identificação de seus métodos.
b) Análise da especificação do diagrama de classes e verificação dos parâmetros utilizados para a execução dos
métodos de cada classe.
c) Análise da especificação e do diagrama de Casos de Uso para identificação dos possíveis cenários.
d) Observação, na especificação das classes e do diagrama de classes, sobre o tipo de retorno do método cha-
mado, para sua identificação no diagrama de sequência.
© U5 – Processo de Desenvolvimento de Software – Modelagem de Interações 157

e) Inserir as chamadas realizadas entre as classes, por meio da observação da relação entre instâncias e objetos
utilizados para a execução dessas chamadas.
3) Em relação aos diagramas de colaboração é correto afirmar:
a) Representam o fluxo de dados entre as camadas de objetos.
b) Revelam a ordem das chamadas entre os objetos do sistema.
c) Representam os aspectos comportamentais do sistema, com informações sobre como os objetos interagem
entre si.
d) Ao contrário dos diagramas de sequência, representam o tempo como uma dimensão separada.
e) Todas as alternativas estão incorretas.

Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
1) c.

2) e.

3) c.

16. CONSIDERAÇÕES
Esta unidade mostrou a transição da fase de análise para a fase de projeto. Você poderá
ter dificuldades em perceber essa transição, uma vez que não há marcos que encerrem uma fase
para dar início à outra.
Portanto, na fase de projeto é importante lembrar que o modelo de classes pode sofrer
modificações, uma vez que o modelo conceitual dará, nesse momento, lugar ao modelo de clas-
ses de projeto.
Além disso, você estudou o modelo de interações, que é importante para mostrar como
os objetos trocam mensagens entre si. Nesse modelo destacamos a relação dos Casos de Uso
com os diagramas de sequência. Os Casos de Uso revelam a funcionalidade do sistema, sem a
preocupação de indicar quais são as classes relacionadas no processo, e nem como os objetos
delas interagem entre si. Mas, é dos cenários dos Casos de Uso que elaboramos os diagramas de
sequência, pois eles nos permitem observar o comportamento desses objetos.
A próxima unidade apresentará a modelagem de estados. Nela além de conhecer o dia-
grama de estados, também conhecerá o diagrama de atividades e o modelo de implementação.
Essa modelagem é dita dinâmica, pois descreve o comportamento dos objetos.

17. REFERÊNCIAS BIBLIOGRÁFICAS


BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.
BOOCH, Grady et al. UML: guia do usuário. Rio de Janeiro: Campus, 2000.
FURLAN, J. D. Modelagem de objetos através da UML. São Paulo: Makron Books, 1998.
PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.

Claretiano - Centro Universitário


Claretiano - Centro Universitário
EAD
Processo de Desenvolvimento
de Software – Modelagem de
Estados
6

1. OBJETIVOS
• Conhecer e aplicar o Diagrama de Estados.
• Conhecer e aplicar o Diagrama de Atividades.

2. CONTEÚDOS
• Diagrama de Estados.
• Diagrama de Atividades.

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Considerando-se o modelo de estados e o Diagrama de Atividades, atente-se aos itens a
seguir, cujos conceitos são de fundamental importância e devem ser estudados com bastante
atenção.
1) Ao elaborar um Diagrama de Atividades, é possível escolher a ordem em que as ativi-
dades serão realizadas.
2) Lembre-se de que só tem sentido a elaboração do Diagrama de Atividades se, nas des-
crições dos casos de uso, não existir qualquer ponto desconhecido no fluxo principal,
alternativo ou de exceção.
3) O Diagrama de Atividades é um tipo especial de Diagrama de Estados. Enquanto o
Diagrama de Estados representa os estados de um objeto, o Diagrama de Atividades
representa os estados de uma atividade.
160 © Análise e Projeto de Sistemas

4) Os Diagramas de Estado são orientados a eventos, enquanto os Diagramas de Ativida-


des são orientados a fluxos de controle.
5) Não fique preocupado se ainda tiver dúvidas. Lembre-se que seu tutor e seus colegas
poderão ajudá-lo a esclarecê-las. Interagir com eles e pesquisar em outras fontes é a
melhor forma de reforçar seu aprendizado.

4. INTRODUÇÃO À UNIDADE
Na unidade anterior, você teve a oportunidade de conhecer o modelo de interações e os
diagramas que o compõem.
Nesta unidade, demonstraremos o modelo de estados, o Diagrama de Atividade e o mo-
delo de implementação.
O modelo de estados é formado por vários Diagramas de Estados, em que cada um re-
presenta o comportamento de uma classe em determinado instante no tempo. Ele revela as
mudanças que ocorrem nos objetos, provocadas por estímulos externos (eventos). Assim como
o modelo de interações, o modelo de estados é classificado como modelagem dinâmica, isto é,
descreve o comportamento dos objetos.
O Diagrama de Atividade é considerado um tipo especial de Diagrama de Estados, pois
ele apresenta os estados de uma atividade, e não os estados de um objeto, que é o caso dos
Diagramas de Estados.
Tanto o modelo de estados, representado pelo Diagrama de Estados, como também o Dia-
grama de Atividade, fazem parte da etapa de projeto, no desenvolvimento de sistemas.
Quando chegamos à fase da implementação do sistema significa que o problema propos-
to foi compreendido, que uma solução foi determinada e que os diagramas foram construídos,
permitindo, assim, que as decisões pudessem ser tomadas para a construção do sistema. Trata-
se da concretização das fases de análise e projeto. Este é o momento da geração do código do
sistema. Você verá quais são as tarefas associadas à produção deste código. Esta etapa é deno-
minada modelagem da implementação.
Vamos agora conhecer os modelos.

5. MODELO DE ESTADOS
No mundo real podemos observar que o estado dos objetos está em constante mudança,
e que essas mudanças podem ser permanentes (sem volta ao estado anterior), ou temporárias
(em um dado momento, o estado anterior pode voltar). Quando um evento interno ou externo
ao sistema ocorre, ele determina a mudança de estado do objeto. E, durante sua vida, um objeto
pode passar por um número finito de estados.
Nos sistemas a situação é muito semelhante. Eventos podem ocorrer externamente ao sis-
tema, provocando a mudança no estado dos objetos, ou seja, alterando o seu comportamento.
Na UML, existe um diagrama capaz de descrever todos os estados possíveis pelos quais
um objeto passa. Trata-se do Diagrama de Transição de Estados, ou Diagrama de Estados ou,
ainda, Diagrama de Máquina de Estados. Ele descreve o ciclo de vida dos objetos de uma classe,
assim como os eventos que causam a mudança de um estado para outro, e as operações que são
executadas por ocasião dessa mudança.
© U6 – Processo de Desenvolvimento de Software – Modelagem de Estados 161

Antes de começarmos a estudar os diagramas de estados, vejamos alguns conceitos im-


portantes para melhor compreensão do diagrama.

Estado
É uma condição ou situação na qual um objeto se encontra em determinado momento
de sua existência, durante a qual ele realiza alguma atividade ou satisfaz alguma condição. Por
exemplo: um pedido está em espera enquanto aguarda a chegada de um livro, mas o mesmo
pedido passa para o estado atendido depois que o livro chega e é entregue ao cliente.
Dessa forma, podemos dizer que um estado representa a condição de um objeto em um
determinado momento.
Na UML, um estado é representado por um retângulo de cantos arredondados, e o nome
do estado é escrito dentro do retângulo. Veja um exemplo na Figura 1, a seguir:

Figura 1 Notação básica da UML para


diagramas de estados.

Um estado inicial é representado por um círculo preenchido, indicando o estado de um


objeto no momento em que ele é criado. Ele apresenta o início das transições que vão gerar as
mudanças de estado do objeto. O estado final é representado por um círculo vazado e, dentro
dele, um círculo preenchido. Significa que, depois desse estado, não há mais transição para ge-
rar mudanças no estado do objeto. Veja as representações, na Figura 2, a seguir, na UML para
os estados inicial e final.

Estado inicial Estado final

Figura 2 Notação básica da UML para estado inicial e estado final.

Transição
É a mudança de um estado para outro. É representada por uma linha que conecta os dois
estados. Portanto, uma transição pode ser entendida como um relacionamento que ocorre en-
tre dois estados, em que um objeto (que representa o estado atual) recebe estímulos para pas-
sar para outro estado. Lembramos que quando ocorre uma transição, o novo estado pode ser o
mesmo que o anterior. Isso ocorre quando a transição sai de um estado e volta para o mesmo
estado. Neste caso, ela é chamada de transição reflexiva ou autotransição. A forma geral para
expressar uma transição é:
evento (lista de parâmetros) [condição de guarda] / ação

Claretiano - Centro Universitário


162 © Análise e Projeto de Sistemas

Há, ainda, outra variação para as transições, chamada de transição interna. É um tipo de
transição que não faz o objeto mudar de estado, mas faz com que uma atividade ou ação ocorra
sem que haja uma mudança de estado. Ela é definida dentro do retângulo que representa o es-
tado. Observe, na Figura 3, a notação básica da UML para transição.

Condição de guarda
É uma expressão de valor lógico, que se utiliza de parâmetros passados no evento, além de
atributos e referências à ligações da classe em questão. Se a transição não tiver uma condição de
guarda associada a ela, ela será disparada todas as vezes que o evento ocorrer. Caso contrário,
a transição somente será disparada se a condição de guarda associada a ela for verdadeira. Na
UML, uma transição com uma condição de guarda pode ser assim representada:

Figura 3 Notação básica da UML para transição.

Evento
É uma ocorrência em determinado momento no tempo, capaz de fazer com que um obje-
to mude de estado, ou seja, a ocorrência de um estímulo (gerado fora do sistema), que faz com
que um objeto mude de um estado para outro.
De acordo com sua natureza, os eventos são classificados em:
a) De chamada: refere-se à solicitação de serviço de um objeto a outro, ou seja, quando
um objeto recebe uma mensagem de outro objeto.
b) De sinal: quando um objeto recebe um sinal de outro objeto. Difere do evento de
chamada pelo fato de que o objeto que envia o sinal continua o seu processamento
após tê-lo enviado, ao contrário do evento de chamada em que o objeto que envia a
mensagem e aguarda sua execução.
c) De tempo: também conhecido como temporal, é causado pela passagem de um inter-
valo de tempo, ou ocorrência de um momento determinado.
d) De mudança: ocorre pela mudança de uma condição, que se torna verdadeira. Repre-
sentado por uma expressão de valor lógico e a cláusula when, denotando a mudança
de estado do objeto quando a condição relacionada à cláusula when for verdadeira.
Por exemplo: when (estoque < 3).

Ação e atividade
Você sabe diferenciar uma ação de uma atividade? Elas parecem ser algo tão próximo,
que às vezes não percebemos a diferença. Entretanto, a ação ocorre quando um objeto passa
de um estado para outro, e fica representada na linha de transição. Já a atividade é executada
pelo objeto. Portanto, uma ação está associada a uma transição, enquanto uma atividade está
associada a um estado.

Ponto de junção
Dependendo do valor da condição de guarda, o estado de um objeto pode variar. Ou seja,
caso o valor da condição de guarda seja verdadeiro, o objeto passa para um determinado esta-
© U6 – Processo de Desenvolvimento de Software – Modelagem de Estados 163

do; caso contrário, o estado seria outro. Para essas ocasiões, o diagrama requer uma represen-
tação, que é feita pelo ponto de junção. Portanto, um ponto de junção possibilita a existência de
uma trajetória pela qual será definido o estado de um objeto, de acordo com o valor da condição
de guarda associada à transição. Veja um exemplo retratado na Figura 4:

Figura 4 Notação da UML para transição com ponto de junção.

Cláusulas entry, exit e do


Ainda falando em ação e atividade, as cláusulas entry, exit e do são utilizadas na especifi-
cação de ações/atividades. Observe a seguir a utilização de cada uma.
• entry: usada para especificar a ação que será executada no momento em que um obje-
to entra em um determinado estado.
• exit: exatamente o contrário da anterior. Especifica a ação que será executada no mo-
mento em que o objeto sai de um determinado estado.
• do: especifica qual(is) atividade(s) será(ão) executada(s) quando um objeto sofre uma
transição de estado.
Essas cláusulas são utilizadas dentro do retângulo. Veja o exemplo a seguir.

Figura 5 Exemplo do uso das cláusulas entry, exit e do.

Claretiano - Centro Universitário


164 © Análise e Projeto de Sistemas

Analisando o exemplo da Figura 5, podemos perceber que:


a) Do Estado inicial para o Estado1 é executada a ação3.
b) Na ocorrência do Evento1 são executadas a ação1 e a ação2.
c) Na ocorrência do Evento2 pode acontecer de não ser executada a atividade1. Isso vai
ocorrer se o Evento2 for disparado antes do término da atividade1.
d) Na ocorrência do Evento3 será executada a ação4 e tem início a execução da ativida-
de1.
A sintaxe utilizada para essas cláusulas é a seguinte:
evento / [ação | atividade]

Estados aninhados ou compostos


Significa "dois ou mais estados dentro de outro estado". Chamamos de estado composto
o estado que contém outros estados. Na UML um estado composto é representado por um re-
tângulo maior, com cantos arredondados, dentro do qual ficam dois ou mais estados simples,
chamados de subestados. Observe o exemplo.

Figura 6 Exemplo de um diagrama de estado com estados aninhados (estado composto).

O Diagrama de Estados da Figura 6 poderia ser, por exemplo, uma máquina para contar
e separar dinheiro, utilizada nas instituições financeiras. Ela possui dois estados: desligado e
ligado. Entretanto, no estado ligado, a máquina pode passar por dois estados: quando está con-
tando dinheiro (contando), e quando está devolvendo o dinheiro (devolvendo). Ambos estão
dentro do estado ligado (aninhamento). O objetivo desse exemplo é o de mostrar os estados
aninhados. Por esse motivo, omitimos as referências aos eventos nas linhas de transição.

Estados concorrentes
É uma ocorrência de dois ou mais estados ao mesmo tempo para um objeto. E esses esta-
dos são independentes entre si, ou seja, a ocorrência de um estado não interfere na ocorrência
do outro. Trata-se de um tipo especial de estado composto. Veja o exemplo:
© U6 – Processo de Desenvolvimento de Software – Modelagem de Estados 165

Figura 7 Exemplo de um Diagrama de Estados concorrentes.

Estado de submáquinas
Assemelha-se a um estado composto. É representado por um retângulo com cantos arre-
dondados, que contém um ícone do lado inferior direito. Nesta representação de um diagrama
de estados concorrentes, apresentado na Figura 7, aparece apenas o superestado. Os subes-
tados estão dentro dele não ficam expostos. Isso o diferencia da representação de um estado
composto. Veja a representação na UML:

Figura 8 Exemplo de um Diagrama de Estado de submáquinas.

Barra de sincronização
Utilizada na representação de estados paralelos. Os estados paralelos ocorrem por se-
paração/bifurcação ou por união/junção. A barra de sincronização é o ponto de divergência
(separação/bifurcação) ou convergência (união/junção).
Na separação/bifurcação ocorre a chegada de um estado e, a partir dele, dois ou mais es-
tados são desencadeados paralelamente, ou seja, um objeto pode estar em mais de um estado
ao mesmo tempo. Sua representação na UML pode ser vista na Figura 9:

Claretiano - Centro Universitário


166 © Análise e Projeto de Sistemas

Figura 9 Representação na UML do uso da barra


de sincronização por separação/bifurcação.

Na união/junção ocorre que, a partir de dois ou mais estados diferentes, há convergência


de todos eles para um único estado. Sua representação na UML pode ser vista na Figura 10:

Figura 10 Representação na UML do uso da barra de


sincronização por união/junção.

Resumindo, podemos considerar que, como os objetos estão agrupados em classes, é


comum falar que um Diagrama de Estados representa o estado de uma classe em determinado
instante do tempo. Se o estado muda, percebe-se uma alteração no comportamento dos obje-
tos da classe. A essa mudança de estado dá-se o nome de transição. Quando observamos um
Diagrama de Estados, Diagrama de Transição de Estados ou, ainda, Diagrama de Máquina de
Estados, enxergamos as operações que o objeto realiza em decorrência do evento produzido.
O Diagrama de Estados apresenta os possíveis estados para um determinado objeto, além de
apresentar os eventos que geram a mudança de estado de um objeto.
Nem todas as classes podem ter o comportamento de seus objetos modelado em um
Diagrama de Estados, mas apenas aquelas cujos objetos apresentem mudanças de estado em
sua execução.
© U6 – Processo de Desenvolvimento de Software – Modelagem de Estados 167

Ao elaborar um Diagrama de Estados, lembre-se de que cada diagrama representa os


eventos relacionados aos objetos de uma classe apenas, ou seja, segundo Blaha e Rumbaugh
(2006, p. 99) "Todos os objetos de uma classe executam o Diagrama de Estados dessa classe, o
qual modela seu comportamento comum".

6. CONSTRUÇÃO DO DIAGRAMA DE ESTADOS


A elaboração de um Diagrama de Estados deve seguir os seguintes passos:
a) Observe o diagrama de classes de projeto e o diagrama de objetos, e identifique os
possíveis objetos dessas classes que passarão por mudança de estado.
b) Identifique os estados relevantes para a classe.
c) Identifique, ainda, para cada objeto, os eventos relevantes.
d) Para cada evento identificado, identifique, também, a transição que ele gera.
e) Defina, para cada estado, os eventos internos e as atividades/ações correspondentes.
f) Defina o estado inicial e o(s) estado(s) final(is).
g) Faça as conexões entre os estados, por meio das transições identificadas.

7. DIAGRAMA DE ATIVIDADES
Existe também o Diagrama de Atividades, que é considerado o mais específico dos dia-
gramas apresentados até o momento. Esta especificidade é em decorrência dele não caber em
qualquer situação apresentada, pois representa a sequência de atividades que acontecem em
determinado processo no desenvolvimento de um sistema. Pode acontecer sob a forma de fluxo
de controle sequencial ou fluxo de controle paralelo (dois ou mais fluxos sendo executados ao
mesmo tempo). O diagrama de atividades é um diagrama relativo aos aspectos dinâmicos do
sistema.
Diferentemente do diagrama de estados, que representa os estados de um objeto, um dia-
grama de atividades representa os estados de uma atividade, por meio de um fluxo de controle
das atividades que acontecem em determinado processo dentro de um sistema. Ele mostra não
apenas os fluxos principais, mas também os alternativos, os de exceção e os concorrentes ao
fluxo principal.
O Diagrama de Atividades é considerado como uma extensão do fluxograma, ferramenta
que já foi bastante utilizada para descrever o fluxo dos processos de um programa. A diferença
básica entre um fluxograma e um Diagrama de Atividades é que os fluxogramas são limitados a
processos sequenciais, enquanto o Diagrama de Atividades modela tanto os processos sequen-
ciais, como também os paralelos.
Os fluxos representados nos diagramas de atividades são aqueles apresentados nas des-
crições dos casos de uso. Elas fornecem informações sobre o fluxo de eventos gerado quando o
caso de uso se realiza.
O diagrama de atividades é útil no processo de compreensão dos requisitos. Por isso, ao
elaborar os diagramas de atividades, o modelo de casos de uso deve ser revisto e, se for neces-
sário, as descrições dos casos de uso podem ser alteradas.
Assim, para a construção de diagramas de atividades é necessário identificar as atividades
nos casos de uso descritos, examinando-se todos os fluxos, ou seja, o principal, os alternativos
e os de exceção.

Claretiano - Centro Universitário


168 © Análise e Projeto de Sistemas

Os diagramas de atividades são utilizados com diferentes objetivos, conforme listados a


seguir:
• Ajudam a esclarecer passos que não ficaram bem definidos nas descrições dos casos
de uso;
• Auxiliam na compreensão do fluxo de trabalho entre os vários casos de uso que com-
põem o sistema;
• Mostram o relacionamento do ator com o processo de negócio com o qual ele está
envolvido.
Ao contrário dos outros diagramas existentes na UML, o Diagrama de Atividades não tem
origem nos trabalhos de Booch, Rumbaugh e Jacobson. Ele teve sua origem em outras técnicas,
tais como os Diagramas de Eventos de Jim Odell, modelagem de estados SDL, modelagem de
workflow e redes de Petri. Estes diagramas têm como característica principal a representação de
comportamentos por meio de processamento paralelo.
Vamos ver, agora, os elementos que compõem o Diagrama de Atividades e sua notação
na UML.

Atividade
Uma atividade é um estado de execução de alguma coisa. A atividade pode ser, por exem-
plo, a execução de uma operação em uma classe. Ela representa algo que o sistema está rea-
lizando, ou seja, é a representação da interação do usuário com o sistema em que o usuário
faz algo e o sistema responde. Mas, uma atividade pode ser também a representação de uma
execução automática realizada pelo sistema. Na UML, uma atividade é representada por um
retângulo de cantos arredondados, com o nome de ação.
Uma vez que um Diagrama de Atividades é um tipo especial de Diagrama de Estados,
considera-se, segundo Bezerra (2007), que um estado neste diagrama possa ser do tipo estado
atividade ou estado ação. A diferença entre eles está no tempo que cada um leva para ser finali-
zado. O estado de atividade demora mais, enquanto o estado de ação ocorre instantaneamen-
te. Veja a representação de um estado atividade ou estado ação na Figura 11.

Figura 11 Representação na UML de um


estado Atividade ou Estado Ação.

Transição
Liga um estado a outro. Representa o término da execução de uma atividade e o início
da execução da próxima atividade. Representada por uma linha com uma seta que aponta para
a atividade que será iniciada no próximo passo. Veja sua representação na UML mostrada na
Figura 12:
© U6 – Processo de Desenvolvimento de Software – Modelagem de Estados 169

Figura 12 Representação na
UML de uma transição.

Decisão
Pode ser de dois tipos. O primeiro é chamado de desvio ou ponto de ramificação. Carac-
teriza-se por possuir uma única transição de entrada e várias transições de saída. Em cada uma
das transições de saída há uma condição de guarda para que se decida por qual fluxo o processo
continuará. Chegando um fluxo de controle ao ponto de ramificação, apenas uma das condições
de guarda será verdadeira. Na UML, a representação de um ponto de ramificação ou desvio é:

Figura 13 Representação na UML de um ponto de ramificação


ou desvio.

No exemplo da Figura 13, quando o fluxo de controle deixa a ação3, a condição de guarda
que tiver o valor verdadeiro é que determina a continuidade do fluxo. Ou seja, se x < 0, o contro-
le do fluxo passará para a ação4; se x = 0, o controle do fluxo passará para a ação9 e, se x > 0, o
controle do fluxo passará para a ação13.
O segundo tipo de decisão é a intercalação, também conhecida por ponto de união. É
exatamente o contrário do ponto de ramificação ou desvio. Trata-se da representação do com-
portamento condicional em que existem duas ou mais condições de entrada convergindo para a
mesma condição de saída. Na UML, a representação pode ser vista na Figura 14:

Claretiano - Centro Universitário


170 © Análise e Projeto de Sistemas

Figura 14 Representação na UML de um ponto de união


ou intercalação.

Barra de sincronização
Na UML, uma barra de sincronização é representada por uma linha mais forte. Utilizada
para ilustrar duas situações: Thread simultânea e Thread condicional. A seguir, veremos cada
uma delas com mais detalhes.
Thread simultânea
Ocorre sob duas formas:
• Separação ou bifurcação. Exibe comportamentos paralelos em que uma atividade, ao
chegar a um ponto, é subdividida em duas ou mais atividades. Um exemplo na UML
pode ser visto na Figura 15:

Figura 15 Representação na UML de uma


separação ou bifurcação.

• Junção ou união. Trata de uma situação contrária à apresentada anteriormente. Mostra


comportamentos paralelos em que mais de uma atividade, ao chegar a um determina-
do ponto, converge para um mesmo ponto. Veja um exemplo na Figura 16, representa-
do no diagrama da UML:

Figura 16 Representação na UML de uma


junção ou união.
© U6 – Processo de Desenvolvimento de Software – Modelagem de Estados 171

Thread condicional
Uma atividade realizada é apresentada somente se a situação da condição declarada na
seta de transição for positiva. Veja um exemplo na UML:

Figura 17 Representação na UML de uma thread condicional.

No exemplo da Figura 17, a ação3 convergirá para a ação7 somente se a condição de guar-
da x > 0 for verdadeira.

Condição de guarda
É o elemento que controla qual transição dentre várias ocorrerá após o término da ativi-
dade. Dispensamos o exemplo, pois ele pode ser visto nas figuras anteriores, como na Figura 17.
A transição que parte da ação3 para a barra de sincronização carrega em si uma condição de
guarda: x > 0.

Início de fluxo
Também conhecido como estado inicial do processo. Na UML sua representação é feita
por um círculo preenchido, conforme mostra o exemplo da Figura 18.

Figura 18 Representação na UML de


um início de fluxo ou estado inicial.

Fim de subfluxo
Um mesmo processo pode ter diversos pontos de saída, ou seja, vários estados finais.
O subfluxo de um processo é representado por um círculo vazado, com um círculo preenchido
dentro dele. A Figura 19 mostra sua representação na UML.

Figura 19 Representação na UML


de um fim de subfluxo.

Claretiano - Centro Universitário


172 © Análise e Projeto de Sistemas

Fim de fluxo
Um processo pode ter apenas um ponto de fim de fluxo. Na UML, ele é representado por
um círculo vazado preenchido com um X. Veja o exemplo mostrado na Figura 20:

Figura 20 Representação na
UML de um fim de fluxo.

Raias de natação ou swimlanes


Separam, em compartimentos, as atividades que serão realizadas por um agente específi-
co, de forma que fique claro de quem é a responsabilidade pela execução de cada atividade no
fluxo do processo. São representadas por linhas verticais ou horizontais, e seu uso não é obri-
gatório. Entretanto, se utilizadas, deixam o diagrama mais organizado. Veja um exemplo dessa
organização, utilizando-se a UML, na Figura 21:

Figura 21 Representação na UML de raias de natação ou swimlanes.

Construção do Diagrama de Atividades


Para construir o Diagrama de Atividades, observe e execute os passos a seguir:
• Identificar os cenários a serem reproduzidos no Diagrama de Atividades, na descrição
dos casos de uso.
• Com base na descrição do caso de uso que contém o cenário a ser modelado, identifi-
que as atividades básicas e inicie a modelagem por elas. Gradualmente, observe novas
funcionalidades que possam ser acrescentadas ao fluxo principal; em seguida, observe
os fluxos alternativos e os de exceção.
© U6 – Processo de Desenvolvimento de Software – Modelagem de Estados 173

• Lembre-se de que, com o uso das raias (ou swimlanes) o diagrama mostra, com mais
clareza, as atribuições das responsabilidades aos agentes externos, deixando-o mais
organizado e fácil de interpretar.
Vimos, então, que os Diagramas de Atividades podem ajudar os desenvolvedores na com-
preensão de processos mais complexos, pois eles mostram, graficamente, como as atividades
evoluem, passo a passo, na sua execução. Eles documentam as etapas necessárias para imple-
mentar uma operação.
Blaha e Rumbaugh (2006) sugerem algumas orientações para os diagramas de atividades.
São elas:
a) Não abuse dos diagramas de atividades. Eles apenas servem como apoio para o de-
senvolvimento e refinamento dos modelos de casos de uso e de sequência, pois au-
xiliam os desenvolvedores no processo de compreensão dos algoritmos e fluxos das
atividades que compõem os cenários.
b) Nivele os diagramas. As atividades devem ser apresentadas em um nível consistente
de detalhes.
c) Cuidado com os desvios e condições. Considere que, no caso de existirem condições,
uma delas deve ser satisfeita quando uma atividade for concluída.
d) Cuidado com as atividades concorrentes. Certifique-se de que antes de ocorrer uma
junção, todas as entradas tenham sido completadas.
e) Considere os diagramas de atividades executáveis. Eles ajudam os desenvolvedores e,
até mesmo, usuários finais a compreenderem melhor seus sistemas.

8. QUESTÕES AUTOAVALIATIVAS
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:
1) (POSCOMP – 2006) A notação da Unified Modeling Language (UML) que descreve a sequência de atividades
com suporte para comportamento condicional usando branches e merges e comportamento paralelo usando
forks é:
a) Casos de uso.
b) Diagrama de sequência.
c) Diagrama de classes.
d) Diagrama de Atividades.
e) Diagrama de Estados.
2) (POSCOMP – 2004) A linguagem de modelagem UML contém a definição de vários diagramas que permitem
representar diferentes partes de um modelo de sistema tipicamente aplicada a sistemas orientados a objetos.
Analise as seguintes afirmações referentes à UML:
I. Diagramas de Casos de Uso permitem uma descrição do escopo e do comportamento pretendido do
sistema por meio da representação das interações entre atores e o próprio sistema.
II. Diagramas de Estado são similares a Diagramas de Atividade, mas uma diferença básica entre eles é
que os primeiros representam comportamento que causa mudanças de estado de um simples ele-
mento (tipicamente um objeto) e são usados, geralmente, durante o projeto do software, enquanto
os segundos representam comportamento entre diferentes elementos e geralmente são usados para
modelar os fluxos das atividades de negócios durante a análise do software.
III. Diagramas de Sequência representam as interações entre objetos para a realização de algum compor-
tamento do sistema, dando ênfase à ordenação temporal das trocas de mensagens entre os objetos.
Levando-se em conta as três afirmações I, II e III acima, identifique a única alternativa válida:
a) Apenas I e II estão corretas.
b) Apenas II e III estão corretas.
c) Apenas I e III estão corretas.
d) As afirmações I, II e III estão corretas.
e) Apenas a III está correta.

Claretiano - Centro Universitário


174 © Análise e Projeto de Sistemas

Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
1) d.

2) d.

9. CONSIDERAÇÕES
Esta unidade apresentou o modelo de estados e o Diagrama de Atividades. É importante
consideramos o modelo de estados, pois por meio dele conseguimos visualizar as mudanças
no comportamento das classes, conforme os eventos ocorrem. Vale ressaltar que o modelo de
estados é composto por vários diagramas de estados, sendo um para cada classe.
Na Unidade 7 você conhecerá os aspectos relacionados à arquitetura de um sistema orien-
tado a objetos, e verá também como são compostas as arquiteturas lógica e física de um siste-
ma. Além disso, estudará os diagramas utilizados na representação dessas arquiteturas.

10. REFERÊNCIAS BIBLIOGRÁFICAS


BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BLAHA, M. RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. 3. reimpressão. Rio de Janeiro: Elsevier,
2004.
EAD
Processo de Desenvolvimento
de Software – Arquitetura do
Sistema
7

1. OBJETIVOS
• Conhecer os aspectos relacionados à arquitetura de um sistema de software orientado
a objetos.
• Familiarizar-se com os diagramas que fazem parte da arquitetura do sistema.
• Entender a camada de interface e a camada de persistência.

2. CONTEÚDOS
• Apresentação dos conceitos relacionados à arquitetura de um sistema.
• Arquitetura lógica e arquitetura física.
• Apresentação dos diagramas utilizados na definição da arquitetura do sistema: Diagra-
ma de Componentes e Diagrama de Implantação.
• Diagrama de interação geral.
• Camada de interface.
• Camada de persistência.

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Esta unidade apresenta os aspectos relacionados ao desenvolvimento da arquitetura de
software. Trata-se das últimas preparações do projeto antes da implementação. As sugestões
que seguem estão relacionadas a importantes tópicos, aos quais você deve estar bem atento.
176 © Análise e Projeto de Sistemas

1) O projeto de arquitetura é responsável pela definição dos subsistemas que compõem


um sistema de software orientado a objetos. Certifique-se de compreender a impor-
tância desta fase, pois ela é quem vai definir como o sistema será particionado, assim
como as interfaces responsáveis pela comunicação entre estas partes.
2) Saiba diferenciar a arquitetura lógica da arquitetura física de um sistema, porém, en-
xergue-as como atividades complementares.
3) Certifique-se de compreender bem os princípios de coesão e acoplamento.
4) Será apresentado a você o conceito da arquitetura em camadas. Entenda o que são as
camadas de software e sua aplicação.
5) Certifique-se de compreender o conceito de componente e interface. Estude o Diagra-
ma de Componentes e veja a sua importância no processo de modelagem de software
orientado a objetos. Saiba diferenciar componente de interface.
6) Certifique-se de compreender o conceito de nó, utilizado no Diagrama de Implanta-
ção. Estude o Diagrama de Implantação e veja a sua importância no processo de mo-
delagem de software orientado a objetos. Saiba diferenciar nó de componente.
7) Atente-se ao desenvolvimento da camada de interface e veja a importância da criação
do diagrama de estados de navegação, ao considerar interfaces baseadas em janelas.
8) Mesmo sabendo que existem, atualmente, ferramentas que geram a camada de per-
sistência automaticamente, procure compreender os mecanismos de mapeamento
do modelo de objetos para o modelo relacional.

4. INTRODUÇÃO À UNIDADE
Na unidade anterior você estudou o modelo de estados, formado pelos diagramas de es-
tados e teve a oportunidade de compreender que eles representam o comportamento de uma
classe em certo instante do tempo. Além disso, estudou também o diagrama de atividades e o
modelo de implementação.
Quando chegamos à fase da implementação do sistema significa que o problema propos-
to foi compreendido, que uma solução foi determinada e que os diagramas foram construídos,
permitindo, assim, que as decisões pudessem ser tomadas para a construção do sistema. Trata-
se da concretização das fases de análise e projeto. Este é o momento da geração do código do
sistema. Você verá quais são as tarefas associadas à produção desse código.
Um sistema de software orientado a objetos (SSOO) pode ser dividido em subsistemas,
ou seja, os subsistemas compõem o software e interagem entre si por meio de interfaces. Jus-
tamente por serem partes de um sistema maior, os subsistemas colaboram entre si para que as
tarefas do sistema sejam realizadas. De acordo com Bezerra (2007), existem vantagens nessa
divisão do sistema em subsistemas. São elas:
• Como os subsistemas são unidades de tamanho menor, a complexidade do sistema
diminui.
• Com os subsistemas, torna-se mais simples praticar o reuso dos componentes.
E, como ocorre essa divisão do sistema em partes menores? Ocorre na fase da elaboração
do projeto de arquitetura do sistema. A arquitetura de um sistema pode ser entendida como a
estrutura organizacional do mesmo.
Dois aspectos são bastante importantes na fase de projeto da arquitetura do sistema. O
primeiro relaciona-se à própria divisão do sistema em subsistemas, em que deve ser definida a
forma como as classes ficarão distribuídas pelos subsistemas. O segundo refere-se à definição
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 177

de como os subsistemas ficarão dispostos fisicamente pelos nós de processamento no momento


de sua implantação.
Vejamos, então, os aspectos relacionados à arquitetura do sistema.

5. ASPECTOS DA ARQUITETURA DO SISTEMA

Arquitetura lógica
Neste tópico será apresentado os aspectos da arquitetura do sistema e você verá que o
projeto da arquitetura considera dois aspectos importantes quando se trata de sistemas orien-
tados a objetos. O primeiro deles é que os objetos e os relacionamentos entre eles (troca de
mensagens) são o centro deste tipo de sistema. Portanto, se o sistema sofre decomposição,
conforme você viu anteriormente, é importante definir como as diferentes classes desse sistema
estarão distribuídas pelos subsistemas.
Para melhor compreensão sobre o que seja a arquitetura lógica de um sistema, vejamos
alguns conceitos importantes.
• Subsistema: parte de um sistema. Como estamos considerando os sistemas de software
orientados a objetos, os subsistemas correspondem às classes que compõem o sistema.
• Interface: refere-se a um conjunto de serviços fornecidos ou utilizados pelos subsiste-
mas.
Assim, podemos entender que um subsistema, por meio de sua interface, oferece serviços
que outro subsistema utiliza. Isso faz com que exista, entre estes subsistemas, um relaciona-
mento de dependência. Dois subsistemas interagem quando um necessita dos serviços que o
outro pode oferecer.
Um diagrama de subsistemas representa graficamente os componentes que formam um
sistema de software orientado a objetos. A representação gráfica para um subsistema pode ser
vista na Figura 1:

Figura 1 Notação da UML para subsistema.

Uma das etapas do projeto da arquitetura lógica é, depois da decomposição do sistema


em subsistemas e da identificação de suas interfaces, a associação das classes aos subsistemas
correspondentes. Para que as classes sejam alocadas aos subsistemas, devemos começar pelo
diagrama de classes de projeto. São identificadas as classes mais importantes e, para cada uma
delas é criado um subsistema. Para as classes consideradas menos importantes, observa-se a
qual classe de maior importância ela se relaciona, e associa-se a classe de menor importância
ao mesmo subsistema ao qual a classe de maior importância está associada. Uma classe deve
ser alocada a um único subsistema, e este é quem mostra as propriedades desta classe, ou seja,
seu nome, atributos e suas operações.

Claretiano - Centro Universitário


178 © Análise e Projeto de Sistemas

Vimos na Unidade 5 os princípios de acoplamento e coesão. Ambos podem ser aplicados


na definição da arquitetura lógica do sistema. O acoplamento entre os subsistemas deve ser
baixo, ou seja, manter baixo o nível de dependência entre os subsistemas. Para isso, deve ser
mínimo o número de associações entre classes que estão em subsistemas diferentes. Quanto
ao princípio de coesão, deve ser alto dentro dos subsistemas. Isso significa que deve haver mais
associações entre os elementos que estão dentro do subsistema, do que entre elementos que
se encontram em subsistemas diferentes.
Há, ainda, outra consideração a ser relevada quando se trata da alocação das classes aos
subsistemas. Devem ser evitadas as dependências cíclicas entre os subsistemas. Caso isso ocorra,
o recomendado é a divisão de um subsistema do ciclo em pelo menos dois outros subsistemas.
Ainda, em relação à arquitetura lógica, é importante observar como os subsistemas vão
interagir na troca de serviços. Existem duas formas pelas quais os subsistemas interagem. Uma
delas é chamada de arquitetura ponto a ponto e, a outra, é chamada de arquitetura cliente-
servidor. A forma como os subsistemas interagem é que vai determinar como eles serão fisica-
mente distribuídos pelos nós de processamento.
Em se tratando de sistemas orientados a objetos você já deve ter ouvido alguém falar
em programação em camadas. A programação em camadas é utilizada na arquitetura cliente-
servidor. A distribuição do software em camada disponibiliza os serviços mais genéricos nas
camadas inferiores e, nas superiores, os mais específicos.
Nessa arquitetura, o cliente deve conhecer a interface do servidor, ao contrário da ar-
quitetura ponto a ponto, em que é necessário que os subsistemas que vão interagir entre si te-
nham conhecimento da interface um do outro. Os subsistemas envolvidos assumem, ao mesmo
tempo, o papel de cliente e de servidor.
Sabendo-se que os subsistemas fornecem serviços para outros por meio de sua interface,
vamos imaginar como seria a comunicação entre dois subsistemas quando consideramos a ar-
quitetura ponto a ponto. A comunicação pode ocorrer do ponto X para o ponto Y e vice-versa,
ou seja, é uma comunicação de duas vias em que X deve ter conhecimento da interface de Y, e
Y deve ter conhecimento da interface de X.
Assim, se um subsistema vai requisitar serviços do outro, ambos devem conhecer a inter-
face um do outro. Há diferenciação no desempenho dos papéis dos subsistemas. Um faz o papel
de cliente e, o outro, de servidor.
Quando a arquitetura é cliente-servidor, a comunicação só ocorre do cliente para o ser-
vidor, ou seja, só o cliente pode requisitar. Trata-se de uma comunicação de uma via. Portan-
to, apenas o cliente deve ter conhecimento sobre a interface do servidor. Os subsistemas na
arquitetura cliente-servidor são as camadas. Assim, uma camada é um software que pode ser
executado. Por exemplo, uma camada pode ser uma classe ou um componente. Quando se fala
em camadas de software, podemos entender como se estas camadas estivessem formando uma
pilha, na qual a especialização do software se dá de baixo para cima, ou seja, quanto mais alta
a camada, tanto mais específico ao sistema é o serviço. Uma das vantagens dessa arquitetura
refere-se à portabilidade do software e à facilidade para mudanças. Assim, podemos dizer que
as camadas de software relacionam-se com a forma como os diferentes componentes estão
distribuídos pelo sistema.
A arquitetura lógica dos sistemas apresenta, ainda, uma classificação quanto a que servi-
ços podem ser utilizados por quem entre os subsistemas que formam as camadas. Pode ser uma
arquitetura fechada, quando determinado componente de uma camada apenas utiliza serviços
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 179

de sua própria camada, ou da camada inferior à sua. Ou, pode ser uma arquitetura aberta,
quando componentes de uma camada utilizam serviços de qualquer camada inferior à sua.
Segundo Bezerra(2007), um sistema de software orientado a objetos tem uma organiza-
ção típica de suas camadas, embora não haja uma padronização definida para isso, da seguinte
forma:
a) Apresentação: é a camada formada pelas classes que determinam a funcionalidade
para que os usuários visualizem os dados. Encontram-se, aqui, as classes de fronteira
(por nós estudadas no diagrama de classes de análise).
b) Aplicação: é a camada intermediária entre os componentes da camada de apresen-
tação e os componentes da camada de domínio. Controla o fluxo da aplicação e a na-
vegação do usuário pelo sistema. Nesta camada estão as classes de controle (por nós
estudadas no diagrama de classes de análise).
c) Domínio: camada responsável por tratar os requisitos. Nela ocorrem as validações das
regras de negócio e dos dados vindos da camada de apresentação.
d) Serviços técnicos: camada mais genérica, que oferece serviços diversos como, por
exemplo, mecanismos de armazenamento, além de permitir a comunicação do siste-
ma com outros sistemas.
Para esta arquitetura, na sequência da exposição, a camada de apresentação é a menos
genérica, e a de serviços técnicos é a mais genérica. Nesta sequência temos, também, que a
camada mais à esquerda requisita serviços da camada à sua direita. Por exemplo, a camada de
apresentação requisita serviços da camada de aplicação. As vantagens são o incentivo ao reuso
e o baixo acoplamento entre as camadas. Além disso, a divisão em camadas aumenta a manute-
nibilidade e a flexibilidade do sistema.

Arquitetura física
A arquitetura física está relacionada com a implantação física do sistema, ou seja, com a
forma como os subsistemas estão dispostos pelos nós de processamento. Isso é bastante im-
portante quando se trata de sistemas de grande porte e torna-se necessário saber quem são os
componentes físicos do sistema, assim como as interdependências entre eles e sua distribuição
pelas camadas lógicas do sistema.
Veremos, a seguir, o que é necessário fazer quando o sistema está pronto e será dispo-
nibilizado ao cliente. Depois de prontas, as tarefas de implantação podem sofrer variações, de
acordo com o tipo e a complexidade do sistema. Obviamente que, quanto mais complexos, mais
detalhes são dispensados a essa fase.
Para compreendermos bem como funciona a distribuição dos subsistemas pelos nós de
processamento, vamos ver como a alocação de camadas pode acontecer. Consideremos sempre
a arquitetura cliente-servidor.
A arquitetura cliente-servidor em duas camadas é uma arquitetura que caiu em desuso
após o surgimento da internet. Basicamente, ela funciona da seguinte forma: o sistema divide a
interação com o usuário. Aqui, a camada de apresentação fica na máquina do usuário, e é res-
ponsável pela interface gráfica com ele. As demais camadas lógicas correspondem ao servidor,
e a outra máquina, com capacidade maior serve a vários clientes. O cliente pode ser classificado
como gordo ou magro. Um cliente gordo contém a interface gráfica com o usuário e a lógica
da aplicação (se não toda, sua maior parte). Já o cliente magro caracteriza-se por ter apenas a
camada de apresentação, enquanto o processamento da lógica da aplicação fica no servidor. A
arquitetura em duas camadas é recomendada quando o número de clientes não é grande.

Claretiano - Centro Universitário


180 © Análise e Projeto de Sistemas

A outra arquitetura refere-se aos sistemas cliente-servidor em três ou quatro camadas. Na


arquitetura em três camadas, a divisão fica assim:
• A camada lógica de apresentação fica um nó de processamento;
• As camadas da aplicação e domínio ficam em outro nó (nó do meio e que corresponde
à camada física), que fica associada ao servidor da aplicação, a quem a camada de apre-
sentação requisita serviços.
A camada do meio acessa, também, um outro nó de processamento, relacionado ao arma-
zenamento persistente (por exemplo, um sistema gerenciador de banco de dados).
Como estamos considerando sistemas de software orientados a objetos, temos que os
componentes são compostos por diversos objetos. E, uma vez que um componente de software
pode ser utilizado na construção de vários sistemas, e que também pode ser substituído por
outro de mesma funcionalidade, torna-se fundamental definir quais são os componentes que
formarão cada camada.
Mas, antes de continuarmos nossos estudos, é preciso que você compreenda bem o que
é um componente. Para tanto é fundamental que você saiba a diferença entre modelo e com-
ponente. Conforme estudamos nas unidades anteriores, um modelo é algo que se pretende
reproduzir, enquanto o componente é a própria reprodução, não abstrata, mas física e executá-
vel, ou seja, o próprio código, com o objetivo de se adaptar e realizar interfaces para constituir
o software como um todo.

Representação da arquitetura física de um sistema


Para representar a arquitetura física de um sistema a UML dispõe de alguns diagramas.
Eles são os diagramas estruturais, e são divididos em duas categorias: Diagrama de Componen-
tes e Diagrama de Implantação.
O Diagrama de Componentes mostra os vários componentes de software e suas depen-
dências. Para entendermos o que são os componentes, pensaremos primeiro nas classes. As
classes são os blocos de construção, e os componentes são as implementações físicas deles. Eles
são parte física de um sistema, e podem ser substituídos e/ou reutilizados. Esses diagramas nem
sempre são necessários no momento da implantação de um sistema. Essa necessidade depen-
derá da complexidade do sistema. Normalmente são utilizados em sistemas distribuídos. Nesse
caso, as camadas lógicas são distribuídas pelos diferentes pontos de processamento. Vejamos,
agora, os diagramas que representam a arquitetura física de um sistema.

6. DIAGRAMA DE COMPONENTES
O objetivo do diagrama de componentes é mostrar a arquitetura de um sistema de software
orientado a objetos por meio de seus componentes. Ele mostra como os diversos componentes
do sistema interagem entre si. Basicamente, um Diagrama de Componentes mostra os vários
componentes em um sistema e suas dependências. As dependências entre os componentes
mostram como as mudanças em um componente podem causar, também, mudanças em outros
componentes.
A importância da alocação dos componentes aos nós físicos está relacionada com a dis-
tribuição da carga de processamento do sistema. Por isso, ao alocar os componentes, alguns
fatores devem ser considerados pelos responsáveis pela modelagem do sistema. Dentre eles,
podemos destacar:
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 181

a) Dois ou mais componentes terão processamento simultâneo?


b) Nós com maior capacidade computacional devem receber os componentes com mais
exigência de processamento.
c) Componentes com processos mais relacionados (mais próximos) devem estar aloca-
dos ao mesmo nó.
d) Alocar os componentes de forma que o tempo de resposta ao processamento deles
seja a melhor possível, minimizando o tráfego pelos canais de comunicação.
e) Observar os critérios de segurança para o sistema em questão.
Estes não são todos os fatores a serem considerados. Mas, observando-os, podemos per-
ceber que a forma como é definida a arquitetura de software influencia diretamente na forma
como um sistema atenderá aos requisitos não funcionais.
O diagrama de componentes deve ser elaborado depois que os diagramas de classes
e de sequência estiverem feitos. É um diagrama da fase de projeto do desenvolvimento de
software.
Para melhor compreender este diagrama, vejamos alguns conceitos e notações da UML
relacionados a ele.

Componente
O componente corresponde à implementação física das abstrações obtidas pelos diagra-
mas de classes.
Como pontos diferenciais entre classes e componentes podemos destacar:
• Classes representam abstrações lógicas, enquanto os componentes implementam um
conjunto de elementos lógicos.
Classes podem ter atributos e métodos diretamente nelas declarados, enquanto os com-
ponentes têm métodos que só são acessados por meio de suas interfaces. Veja um exemplo na
Figura 2, a seguir.

Figura 2 Notação da UML


para componente.

Veja como fica o diagrama de componentes para o Sistema de Avaliações por nós aqui
estudado, representado na Figura 3.

Claretiano - Centro Universitário


182 © Análise e Projeto de Sistemas

Figura 3 Diagrama de Componentes para o Sistema de Avaliações.

Interface
Uma interface é um conjunto de operações que definem os serviços de uma classe e/ou
componente. Pode definir, de forma total ou parcial, os serviços que serão utilizados ou forne-
cidos por um componente. A interface é representada graficamente por um círculo, e em sua
forma expandida, por uma classe estereotipada como << Interface >>. Cada interface representa
um papel desempenhado por uma classe. Conforme vimos no tópico de arquitetura lógica, as
interfaces possibilitam um aumento da flexibilidade e manutenibilidade. Uma interface pode
ser categorizada como uma interface fornecida ou como uma interface requerida. É pelo rela-
cionamento entre dois componentes que se conhece o componente que requer a estrutura de
outro, e o componente que fornece a estrutura requerida por outro componente.
Portanto, como pontos diferenciais entre interfaces e componentes podemos destacar:
a) Interface fornecida: é aquela que um componente oferece como serviço para outros
componentes.
b) Interface requerida: é aquela que um componente utiliza.
c) Um componente pode importar e exportar várias interfaces.
d) Uma mesma interface que um componente utiliza é realizada por classes que ele im-
plementa.
Além dos componentes que interagem com as interfaces definidas, todos os outros tipos
de artefatos que farão parte do sistema podem ser representados, tais como arquivos executá-
veis, bibliotecas, tabelas etc.
Da esquerda para a direita temos as diferentes representações para interfaces, conforme
pode ser observado na Figura 4:
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 183

• Interface normal (representada por um estereótipo);


• Interface fornecida (representada por um círculo);
• Interface requerida (representada por um meio círculo).

Figura 4 Notação da UML para interfaces.

Em relação à estrutura interna a ser implementada pelos componentes, há dois tipos de


visões. O primeiro tipo é chamada de visão "caixa-preta". Isso ocorre quando a estrutura interna
que o componente vai implementar não é demonstrada, mas apenas as interfaces requeridas e
fornecidas. O outro tipo de visão é chamada de visão "caixa-branca", exatamente o contrário da
anterior, ou seja, quando a estrutura interna a ser implementada pelo componente é revelada.

Relacionamentos
Um relacionamento é representado, na UML, como uma seta pontilhada. Trata-se do re-
lacionamento de dependência. Ele ocorre entre dois componentes em que a alteração no com-
ponente independente pode alterar o componente dependente. Observe, na Figura 3, as setas
tracejadas que ligam os componentes. Essas setas representam os relacionamentos.

Portas
As portas representam a comunicação dos elementos internos de um componente com o
ambiente externo. São representadas por um quadrado que pode ficar em qualquer extremida-
de do componente. Veja, na Figura 5, a notação na UML para portas:

Figura 5 Notação da UML para porta.

Veja, agora, na Figura 6, outro exemplo de diagrama de componentes, utilizando os prin-


cipais elementos que o compõem.

Figura 6 Exemplo de um Diagrama de Componentes.

Claretiano - Centro Universitário


184 © Análise e Projeto de Sistemas

7. CONSTRUÇÃO DO DIAGRAMA DE COMPONENTES


Para construir um Diagrama de Componentes são necessários os seguintes procedimentos:
• Observar os diagramas de classes e de sequência, para identificar as classes que com-
põem o sistema e que devem fazer parte dos componentes.
• Definir com quais estereótipos os componentes serão representados, e de forma estes
estereótipos colaboram para a compreensão do significado dos componentes.
• Definição das interfaces a serem acessadas pelos componentes.

8. DIAGRAMA DE IMPLANTAÇÃO
O Diagrama de Implantação representa a configuração e a arquitetura de um sistema no
qual os componentes estarão ligados. É um diagrama que modela a visão estática de um sis-
tema, especificando aspectos relacionados à sua construção. Os componentes representam a
distribuição dos artefatos ou recursos da aplicação pelos pontos da topologia de hardware no
qual o sistema será executado. Isso significa que o Diagrama de Implantação mostra quem são
os dispositivos de hardware e as interfaces físicas, tais como impressora, disco, memória, re-
presentadas por seus estereótipos. Os recursos representados são chamados de "nós" e esse
diagrama é, também, conhecido como Diagrama de Execução.
O Diagrama de Implantação é útil aos profissionais envolvidos com o ambiente de hardware
e de software no qual o projeto será desenvolvido, pois ele permite, entre outras coisas, visualizar
a dimensão do software e  da rede, com a distribuição dos componentes do sistema pelos nós. Os
servidores são comumente representados nesse diagrama.
Vejamos alguns conceitos relacionados com o diagrama de implantação e sua notação na
UML.


O Nó representa os elementos que compõem um diagrama de implantação. Na UML sua
representação é feita por um cubo tridimensional. Veja o exemplo a seguir mostrado na Figura 7:

Figura 7 Notação na UML


para nó.

Relacionamento
O relacionamento representa uma associação entre dois nós. Pode ser de dois tipos neste
diagrama:
• Dependência: a alteração em um nó independente altera o nó dependente. Represen-
tado por uma seta tracejada, conforme é mostrado na Figura 8.
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 185

Figura 8 Notação da UML para relacionamento de dependência.

• Associação: representa uma comunicação entre dois nós, na qual um estereótipo es-
pecifica o tipo de comunicação. Na UML sua representação pode ser por uma linha ou
por uma seta direcional, de acordo com a Figura 9.

Figura 9 Notações da UML para relacionamento de associação.

O Diagrama de Implantação deve ser construído na fase de projeto do desenvolvimento


de software, pois serve de apoio para a definição e construção da arquitetura física e da implan-
tação do sistema. É bastante específico para a modelagem de sistemas do tipo cliente-servidor
e sistemas distribuídos.

9. CONSTRUÇÃO DO DIAGRAMA DE IMPLANTAÇÃO


Para construir um diagrama de componentes são necessários os seguintes procedimen-
tos:
a) Identificação dos dispositivos e processadores a serem utilizados pelo sistema.
b) Identificação dos componentes a serem executados em cada nó.
c) Nomeação dos nós, utilizando estereótipos que colaborem para a compreensão do
significado dos componentes.
d) Definição dos relacionamentos entre os nós.
A seguir, a Figura 10 apresenta o Diagrama de Implantação para o Sistema de Avaliações,
por nós estudado.

Figura 10 Diagrama de Implantação para o Sistema de Avaliações.

Claretiano - Centro Universitário


186 © Análise e Projeto de Sistemas

10. DIAGRAMA DE INTERAÇÃO GERAL


É um diagrama que foi incorporado à UML 2.0 com o objetivo de dar uma visão geral dos
diversos cenários de um caso de uso. Portanto, ele foi criado para demonstrar um modelo quan-
do é necessário representar uma visão da interação de vários diagramas. Considerado um tipo
especial de diagrama de atividade (por nós já estudado). Será o último diagrama a ser apresen-
tado, pois sua utilização não é bastante comum e, normalmente será criado se houver neces-
sidade da visão da interação dos diagramas de sequência, comunicação e tempo para melhor
compreensão de cenários mais complexos.

Frame
Trata-se da apresentação, por meio dos diagramas de sequência, comunicação ou tempo,
de uma parte de um cenário. Na UML, sua representação é feita por um retângulo, com uma
etiqueta na parte superior, conforme podemos ver na Figura 11.

Nome do Processo

Nome do Processo

Figura 11 Diagrama de Implantação para o Sistema


de Avaliações.

Para elaborar um diagrama de interação geral é necessário, no mínimo, que os diagramas


de sequência estejam criados.

11. CONSIDERAÇÕES IMPORTANTES SOBRE AS CAMADAS DE INTERFACE E


DE PERSISTÊNCIA
Durante a fase de elaboração de um projeto de software é muito importante uma atenção
à camada de interface e à camada de persistência. As decisões tomadas durante a fase de proje-
to devem fazer com que a implementação se torne uma tarefa simples, quase que uma tradução
das decisões tomadas na fase de projeto. Além disso, a implementação deve refletir os resul-
tados de toda preparação e tomadas de decisão que ocorreram nas fases de análise e projeto.
As preparações para a fase de implementação incluem, entre outras, o projeto das camadas de
interface e persistência. A modelagem de implementação visa, também, o ajuste de classes e à
preparação para o teste de software.
A seguir, uma visão destes tópicos importantes.

Camada de Interface
Ao estudarmos a arquitetura lógica, vimos que um sistema de software orientado a obje-
tos está, tipicamente, organizado em camadas. Duas das camadas estudadas foram as camadas
de apresentação e de aplicação. Essas duas camadas são subcamadas da camada de interface.
Considerando que os sistemas são implementados com interfaces baseadas em janelas,
faz-se necessário um planejamento desta camada, com tarefas tais como:
• Definição das janelas que farão parte do sistema;
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 187

• Definir o esquema de navegação entre as janelas;


• Determinar os eventos de navegação e associar a eles os controles necessários (transa-
ção, operações, consultas); 
• Considerando-se os diferentes estados das janelas modais, determinar os controles so-
bre estes estados (habilitados/desabilitados);
• Determinar as funções que poderão ficar habilitadas de acordo com os níveis de segu-
rança, entre outros.
Vejamos, então, quais os pontos a serem considerados no projeto.

Projeto de navegação por entre as janelas que compõem o sistema


O usuário precisa navegar de uma janela para outra. Para isso, duas coisas devem ser
observadas. A primeira consiste em se definir quais são as janelas que fazem parte do sistema.
E, a segunda, é definir quais são os eventos que possibilitarão ao usuário fazer essa navegação.
O documento gerado nesta fase de projeto chama-se Diagrama de Estados de Navegação. Ele
mostra as janelas do sistema e o caminho de navegação do usuário por elas.
Veja, na Figura 12, um exemplo de estrutura de um Diagrama de Estados de Navegação.

Figura 12 Esquema geral para um Diagrama de Estados de Navegação.

Você deve estar lembrado do Diagrama de Estados já estudado. Pois bem, o Diagrama de
Estados de Navegação não deixa de ser um Diagrama de Estados, mas dos estados em que as
janelas se encontram. A passagem de uma janela para outra também ocorre por meio de um
evento que, neste caso, recebe o nome de evento de navegação. E essa passagem de uma janela
para outra é representada por uma transição. Esses conceitos já lhe são familiares. A diferença
nos eventos agora é que, em se tratando de janelas, o evento está associado a um controle da
janela, como, por exemplo, um botão. Este diagrama, tal qual o Diagrama de Estados das classes
(objetos), também tem uma representação para o início e para o fim.
Podemos pensar que cada janela realiza um caso de uso. Então, é necessário que se asso-
cie a cada janela, o caso de uso correspondente. Um fluxo alternativo também é realizado por
alguma janela. Portanto, ao elaborar o diagrama de estados de navegação, defina quem são os
eventos de navegação e o controle a ele associado.
Se uma janela realiza um caso de uso, é necessário definir quem são as operações a serem
realizadas por ela. As operações ficam associadas aos controles de ativação. Pense que para

Claretiano - Centro Universitário


188 © Análise e Projeto de Sistemas

uma operação acontecer, é necessário que ela seja ativada. E isso ocorre quando, por exemplo,
um botão é acionado. Além disso, é necessário que exista um campo de entrada para cada pa-
râmetro utilizado pela operação (por exemplo, uma caixa de texto, entre outros).
Além de operações, um sistema também realiza consultas. Da mesma forma que uma
operação, há necessidade de se definir para elas um controle de ativação e um campo de en-
trada para cada parâmetro utilizado pela consulta. Como se trata de consulta, é preciso, ainda,
definir os campos para a exibição dos resultados produzidos por elas.
Um exemplo de uma janela com os seus controles pode ser:

Figura 13 Esquema para uma janela.

Para melhor completar a especificação das janelas e seus controles, e também contribuir
para aumentar a qualidade de seu projeto, junto com o Diagrama de Estados de Navegação,
você pode gerar um outro documento que estabelece a associação dos controles das janelas às
suas funcionalidades.
Por exemplo, se o controle1 da Figura 13 fosse um botão para ativar cadastro de alunos, o
controle2 fosse um botão para ativar a função de matrícula de alunos, e o controle3 um botão
para ativar o encerramento das operações, então o documento gerado poderia ser esse, mos-
trado na Figura 14:

Botão "Cadastrar Aluno":

Navegação para "Cadastro de Aluno".

Botão "Matricular Aluno":

Navegação para "Matrícula de Aluno".

Botão "Finalizar":

Navegação para "Fim".


Figura 14 Documentação das associações dos controles
de uma janela às suas funcionalidades.

Janelas modais
São aquelas que necessitam de um Diagrama de Estados para mostrar seus diferentes es-
tados de operação. Por exemplo, pense em um sistema de vendas. Deve haver uma janela Fazer
Pedido. Essa é uma janela modal, uma vez que ela tem diferentes estados de operação. Estes
estados podem ser:
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 189

a) Aguardando Pedido
b) Identificando Cliente
c) Abrindo Pedido
d) Pedido em Aberto
e) Pedido Cancelado
f) Pedido Atendido
O Diagrama de Estados da janela modal para o processo Fazer Pedido pode ser visto na
Figura 15:

Figura 15 Diagrama de Estados da janela modal Fazer Pedido.

Um fator ainda a ser considerado, refere-se ao controle de acesso dos usuários às dife-
rentes funções apresentadas por um sistema. Normalmente, nem todos os usuários do sistema
poderão acessar todas as funções, especialmente considerando que, se não todos, mas a quase
totalidade dos sistemas são distribuídos em redes. E isso requer muitos cuidados com a segu-
rança das informações manipuladas por eles.
Para se conhecer as restrições de segurança para um sistema é necessário voltar ao docu-
mento de requisitos. Nele poderão ser verificados os níveis de segurança existentes no sistema,
quais funções podem ser executadas em cada nível e por quem.
Na documentação do sistema, o Diagrama de Estados de Navegação pode mostrar as in-
dicações de segurança. Os níveis de segurança exigidos para navegar nas interfaces aparecem,
neste diagrama, como condições de guarda nas transições.
Além das indicações de segurança no diagrama, é necessário determinar, para cada janela
de navegação, quais os controles o usuário pode ou não ter acesso. Isso significa que usuários com
diferentes níveis de permissão poderão ter ou não acesso aos controles, ou seja, cada controle da
tela poderá estar habilitado ou desabilitado, dependendo do nível de segurança para o usuário.

Camada de Persistência
A camada de persistência é responsável pelo controle dos dados que serão armazenados
no sistema.
Atualmente, existem ferramentas que tratam automaticamente da geração da camada
de persistência, o que torna quase desnecessária uma atenção especificamente para a criação
desta camada. Vamos entender o que acontece na geração da camada de persistência. Dois as-
pectos devem ser considerados.

Claretiano - Centro Universitário


190 © Análise e Projeto de Sistemas

O primeiro, é que a maior parte dos sistemas de software atuais é orientada a objetos, ou
seja, houve uma consolidação da tecnologia de orientação a objetos como forma de desenvol-
vimento de software.
O segundo refere-se à tecnologia de banco de dados. A maior parte dos sistemas ge-
renciadores de banco de dados é relacional. Assim, com esta quase unanimidade pelas duas
tecnologias, torna-se necessário um mapeamento de objetos para o modelo relacional. Isso
ocorre porque as tecnologias envolvidas são muito diferentes, isto é, vindas de princípios muito
diferentes. Na tecnologia da orientação a objetos, temos que os objetos são constituídos de
dados e funções, independentemente da forma como são representados. E, na tecnologia rela-
cional, o armazenamento dos dados é representado por tabelas. Segundo Bezerra(2007), a essa
diferença entre as representações do modelo de objetos e do modelo relacional, dá-se o nome
de impedance mismatch.
Nos sistemas de software orientados a objetos temos duas classificações para os objetos.
Eles podem ser objetos transientes e objetos persistentes. Os objetos transientes são aqueles
que existem apenas durante uma sessão de uso do sistema. Lembrando das classes de análise,
por nós estudadas na fase de análise do desenvolvimento do sistema, são os objetos de contro-
le (das classes de controle) e os objetos de fronteira (classes de fronteira). E, os objetos persis-
tentes são aqueles cuja existência se dá por várias sessões de uso do sistema. São os objetos de
entidade (das classes de entidade). Resumindo, os objetos transientes não ficam armazenados,
enquanto que os objetos persistentes ficam. Os objetos persistentes são armazenados ao final
de uma execução do sistema, e são restaurados ao iniciar outra sessão.
Quando desenvolvemos um sistema orientado a objetos, devemos nos preocupar com o
planejamento do banco de dados relacional. Como qualquer projeto de banco de dados, deve-
mos nos preocupar com o modelo conceitual do banco, que dará origem ao modelo lógico e,
então, com o modelo físico.
Não podemos simplesmente usar as classes definidas no modelo de classes e "transformá-las"
em tabelas do banco de dados. Há uma série de ajustes a serem feitos para que o modelo de objetos
possa se adaptar ao modelo relacional. A esta transição de um modelo para outro, dá-se o nome de
mapeamento (passagem dos valores de atributos de objetos para tabelas).
Como já foi explicado, há atualmente ferramentas CASE que fazem esse mapeamento au-
tomaticamente. O mapeamento consiste em criar um esquema relacional a partir do modelo de
classes. Entretanto, vamos conhecer cada etapa e o que ocorre no mapeamento.
Se você conhece o mapeamento do modelo conceitual para o modelo relacional que ocor-
re nos sistemas gerenciadores de banco de dados relacional, verá que o mapeamento de obje-
tos para o modelo relacional é bastante semelhante a ele.
Embora haja essa semelhança, o modelo de classes não é equivalente ao Modelo Entida-
de-Relacionamento, pois o modelo de classes modela dados e comportamentos dos objetos,
enquanto o Modelo Entidade-Relacionamento é um modelo de dados.
Vejamos, a seguir, os casos mais comuns de mapeamento.

Classes e relações
No mapeamento, as classes passam a ser relações.
• Mapeamento direto de classe para relação: cada atributo da classe passa a ser uma
coluna da relação correspondente.
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 191

• Várias classes podem ser mapeadas para uma única relação.


• Uma classe pode ser mapeada para várias relações.
Quanto aos atributos:
• Um atributo será mapeado para uma ou mais colunas (lembrar que os atributos deriva-
dos normalmente não são mapeados para o banco de dados).

Associações
Quando se trata de associação, utiliza-se o conceito de chave estrangeira. O mapeamento
de associações vai ser determinado pelo tipo de conectividade. Veja como podem ser.
Associação do tipo um para um (1..1)
Neste tipo de associação uma chave estrangeira deve ser adicionada em uma das duas
relações. A decisão sobre em qual relação esta chave será adicionada depende de uma dessas
três situações:
a) Se a associação é obrigatória em ambos os extremos.
b) Se a associação é opcional em ambos os extremos.
c) Se a associação é obrigatória em um e opcional em outro extremo.
No caso (a), a opção deve ser pela relação em que a coluna correspondente à chave es-
trangeira nunca terá valores nulos. Já, nos casos (b) e (c) é opcional a escolha da relação em que
a chave deve ser adicionada.
Outra opção para este tipo de conectividade é mapear as classes para uma única relação,
o que dispensaria o uso da chave estrangeira.
Associação do tipo um para muitos (1..*)
Neste caso, a chave estrangeira será adicionada à relação correspondente à classe Fun-
cionário, para referenciar a chave primária da relação correspondente à classe Departamento,
conforme pode ser observado na Figura 16.

Figura 16 Associação 1..*.

Associação do tipo muitos para muitos (*..*)


Sempre que a conectividade for do tipo muitos para muitos, deve ser criada uma nova
relação, chamada relação de associação. Existem duas possibilidades para este caso:
• A nova relação deve ter, como chave primária, uma chave composta, formada por atri-
butos das duas classes associadas.
• A criação de uma chave primária simples para a relação de associação.
Independentemente da forma como é definida a relação de associação, ela sempre terá
colunas vindas das duas relações associadas. Conforme já estudado, as agregações e composi-
ções são tipos especiais de associação. Assim, o mapeamento que vimos para as associações
pode ser utilizado para agregações e composições. Entretanto, há uma diferença semântica en-
tre elas. Isso significa que, na remoção de um objeto que representa o todo, os objetos parte
também serão removidos. O mesmo ocorre para a recuperação de objetos.

Claretiano - Centro Universitário


192 © Análise e Projeto de Sistemas

Existem, ainda, as associações reflexivas. Neste caso, as mesmas considerações feitas para
as associações devem ser mantidas.

Generalização
Para o mapeamento de generalização, existem três opções, mostradas a seguir.
• Uma relação para cada classe da hierarquia. Para cada classe que compõe a hierarquia,
é criada uma relação. Depois disso, considera-se que os objetos da classe-mãe tenham
uma correspondência unívoca com os objetos de cada classe-filha. Em seguida, aplica-
-se a mesma regra de mapeamento vista para associações de conectividade um para
um.
• Uma única relação para toda a hierarquia. Uma única relação será criada. Ela deverá
ter uma coluna para cada atributo da superclasse e de todos os atributos de todas as
subclasses. Outra coluna, além dessas, servirá para identificar à qual classe da hierar-
quia um objeto de determinada linha pertence.
• Uma relação para cada classe da hierarquia. Cada subclasse da hierarquia terá uma
relação correspondente. Cada relação terá como colunas os atributos da classe corres-
pondente, além de colunas correspondentes a cada atributo herdado da superclasse.
Vimos, neste tópico, algumas das principais formas de mapear as estruturas dos objetos
para o modelo relacional, para que eles possam ser armazenados no sistema gerenciador de
banco de dados, de forma persistente.
Entretanto, existem outros aspectos a serem considerados quando se trata de persistência
de dados. Por exemplo, a restauração de um objeto do banco de dados, além de sua atualização
e remoção. Trata-se da forma como os objetos são transportados entre o sistema e o banco de
dados.
A camada de persistência encarrega-se das funcionalidades relacionadas ao mecanismo
de armazenamento dos dados, isolando-os dos objetos do sistema. Com o fraco acoplamento
entre objetos e o banco de dados, o sistema ganha em flexibilidade e portabilidade, pois fica
mais adaptável a mudanças e ao transporte para outras plataformas.
Lembramos que o uso de ferramentas permite a geração automática da camada de per-
sistência. Todavia, pode ser necessário, algumas vezes, que alguns ajustes nos mecanismos de
persistência sejam feitos, por causa de objetos que apresentam características especiais que
não são mapeadas pela ferramenta, ou ainda para atender a requisitos não funcionais, como de
segurança dos dados ou performance.

12. QUESTÕES AUTOAVALIATIVAS


Sugerimos que você procure responder, discutir e comentar as questões a seguir que tra-
tam da temática desenvolvida nesta unidade.
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:
1) Indique a alternativa que apresenta uma definição correta para Diagrama de Componentes.
a) É um modelo da visão estática da implantação de um sistema e seus relacionamentos.
b) É um modelo que apresenta a arquitetura lógica e as dependências entre os vários componentes de
software.
© U7 – Processo de Desenvolvimento de Software – Arquitetura do Sistema 193

c) É um modelo que apresenta a arquitetura física e as dependências entre os vários componentes de software.
d) É um modelo que apresenta as arquiteturas lógica e física, e as dependências entre os vários componentes
de software.
e) Nenhuma das alternativas está correta.
2) Considere as seguintes afirmativas.
I. Um componente de software é uma implementação física das abstrações obtidas pelos diagramas de clas-
ses.
II. Um componente é uma parte física e pode ser substituída em um sistema.
III. Um componente é uma parte do sistema que é reutilizável.
IV. Componentes representam abstrações lógicas.
V. Componentes têm atributos e métodos acessados por meio de interfaces.
Em relação às afirmativas, indique a alternativa correta.
a) Apenas as afirmativas I, II e III estão corretas.
b) Apenas as afirmativas II e III estão corretas.
c) Apenas as afirmativas II, III e V estão corretas.
d) Apenas a afirmativa IV está incorreta.
e) Apenas as afirmativas I, III e IV estão corretas.
3) Indique a alternativa que apresenta uma definição incorreta para Diagrama de Implantação.
a) Mostra a organização do hardware e a ligação do software aos dispositivos físicos.
b) Modela a visão dinâmica da implantação de um sistema entre seus nós físicos e seus relacionamentos.
c) Auxilia na compreensão da dimensão do software e dispositivos físicos que serão utilizados pelo sistema.
d) Fornece uma visão sobre a rede em seus diversos nós.
e) Representa a arquitetura física de um sistema, por meio da configuração de nós de processamento em tem-
po de execução.

Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
1) c.

2) d.

3) b.

13. CONSIDERAÇÕES
Esta unidade apresentou os aspectos da arquitetura do sistema. Lembre-se de que um sis-
tema pode ser decomposto em subsistemas. E, à definição desses subsistemas dá-se o nome de
projeto arquitetural do sistema. Além disso, a modelagem de sistemas, por meio do modelo de
implementação, permite saber quais são os componentes do sistema, como eles se relacionam
e como estarão distribuídos fisicamente.
Os subsistemas são compostos por classes e eles não estão sozinhos. É importante lem-
brar que eles fazem parte de um sistema. Os subsistemas relacionam-se a partir do momento
em que um utiliza os serviços que o outro fornece.
Para a criação dos subsistemas, normalmente identificamos as classes mais importantes
para o sistema e, para cada uma delas, criamos um subsistema. Após isso, as classes menos
importantes são incorporadas a esses subsistemas. Portanto, um subsistema tem classes que
se relacionam, porém, as classes de um subsistema também vão se relacionar com as de outros
subsistemas (lembre-se de que um subsistema fornece serviços para outro).
É fundamental que você se lembre que dois princípios devem ser considerados quando
trabalhamos com subsistemas. O primeiro deles é acoplamento. Neste princípio é interessante

Claretiano - Centro Universitário


194 © Análise e Projeto de Sistemas

observar que, ao distribuir as classes pelos subsistemas, haverá a garantia de independência no


desenvolvimento de cada um, de forma que o acoplamento entre eles seja fraco (princípio do
acoplamento). Isso significa que o número de associações entre classes que estão em subsiste-
mas diferentes deve ser mínimo.
O segundo princípio é o da coesão, ou seja, dentro de um mesmo subsistema, a depen-
dência entre os seus componentes deve ser alta (princípio de coesão).
Apresentamos dois diagramas importantes. O Diagrama de Componentes, que permite
visualizar as dependências entre os componentes e a utilização das interfaces a tempo de execu-
ção. E, também, o diagrama de implantação, que mostra os componentes utilizados no sistema.
Este diagrama é bastante útil na elaboração dos manuais de instalação e operação do sistema.
Depois que a modelagem está pronta, seja de parte do sistema ou dele todo (dependendo
da metodologia de desenvolvimento escolhida), chega o momento de iniciar a implementação.
Isso significa que tudo aquilo que foi modelado representa o que se quer e o que se espera do
sistema depois de pronto.
Como estamos tratando de sistemas orientados a objetos, uma linguagem de programa-
ção orientada a objetos deve ser escolhida para a escrita dos códigos dos programas. E você
deverá optar por uma linguagem que seja adequada ao sistema que está sendo desenvolvido.
De maneira geral, o mais comum é que um sistema seja dividido em subsistemas, com o
objetivo principal de reduzir a sua complexidade. A esse processo dá-se o nome de projeto da
arquitetura do sistema. Ao final do desenvolvimento, todos os subsistemas são integrados e de-
vem atender aos requisitos que foram especificados na fase inicial do desenvolvimento.
Se o modelo de processo de desenvolvimento do sistema for o iterativo/incremental, ou
seja, aquele que divide o sistema em partes menores a fim de diminuir sua complexidade, a
integração dos subsistemas ocorre a cada novo módulo construído.
Dessa forma, cada vez que uma parte do sistema fica pronta, ela é entregue ao cliente
para que ele faça sua avaliação. Após aprovação do cliente, ele continua utilizando esta parte do
software, até que uma nova também fique pronta. Depois de testada, ela é integrada à anterior.
Assim, o sistema vai aumentando a cada nova parte de software testada e entregue ao cliente,
até que todo o sistema esteja pronto, testado e integrado.
Na próxima unidade você acompanhará um estudo de caso sobre um sistema para contro-
le de alunos de uma universidade. O objetivo é que você visualize, na prática, todos os conceitos
estudados nas unidades anteriores e comece a colocá-los em prática. A unidade apresentará,
também, a ferramenta de modelagem UML Astah Community.

14. REFERÊNCIAS BIBLIOGRÁFICAS


BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. 3. reimpressão. Rio de Janeiro: Elsevier,
2004.
EAD
Estudo de Caso: Sistema de
Controle de Alunos de Uma
Universidade
8

1. OBJETIVOS
• Visualizar, na prática, os principais conceitos estudados nas unidades anteriores, por
meio do desenvolvimento de um estudo de caso sobre um sistema de controle de alu-
nos para uma universidade.
• Conhecer a ferramenta de modelagem UML Astah Community.

2. CONTEÚDOS
• Apresentação do desenvolvimento de um sistema para controle de alunos de uma uni-
versidade.
• Descrição do sistema.
• Apresentação dos requisitos.
• Apresentação das regras de negócio.
• Definição e descrição dos principais Casos de Uso.
• Elaboração do glossário. 
• Identificação das classes de análise.
• Construção do diagrama de classes de análise.
• Construção dos principais diagramas de sequência.
• Construção do Diagrama de Classes de projeto. 
• Construção do Diagrama de Atividades.
196 © Análise e Projeto de Sistemas

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE


Por se tratar da última unidade de estudo, é recomendável, nesta etapa, que você esteja
bem familiarizado com os assuntos estudados até o momento, pois faremos um estudo de caso
que permitirá uma breve revisão do conteúdo e o acompanhamento das etapas mais importan-
tes do levantamento de requisitos e da modelagem de software.
Veja a seguir, os tópicos que devem ser objeto de estudo para esta unidade.
1) Entender bem o que é e quais são os propósitos da Linguagem de Modelagem Unifi-
cada (UML – Unified Modeling Language).
2) Durante o decorrer do estudo desta unidade é importante que você compreenda o
que são os requisitos para um sistema e com que finalidade eles são classificados em
funcionais e não funcionais, é importante também, que saiba como diferenciá-los.
3) Compreender o que são as regras de negócio e a sua importância para o desenvolvi-
mento do software também será uma tarefa que você terá nesta unidade.
4) Lembre-se de que para ter um bom aproveitamento dos seus estudos é fundamen-
tal que conheça e coloque em prática as técnicas de levantamento de requisitos. É
importante que você compreenda essa etapa do desenvolvimento, e saiba avaliar as
consequências para um sistema de software quando essa tarefa não é devidamente
realizada.
5) É importante entender o que são os artefatos de software e quais são os artefatos
produzidos nas diferentes etapas do desenvolvimento de um software.
6) Entender o que são os casos de uso e saber a finalidade que eles são criados é impres-
cindível para o seu aprendizado, por isso fique atento a estes conceitos.
7) Durante o estudo desta unidade, é fundamental que compreenda que existem fer-
ramentas que são abertas e podem ser copiadas para o seu computador. Sugerimos
o Astah Community. No entanto, nada o impede de utilizar outra que já possua ou
conheça. O importante é saber que essas ferramentas nos auxiliam na elaboração dos
desenhos, podem gerar algum tipo de código, imprimem maior qualidade ao projeto etc.

4. INTRODUÇÃO À UNIDADE
Para que você possa rever os conceitos estudados na unidade anterior, de forma prática,
esta unidade tem por objetivo apresentar um sistema para controle de alunos de uma universi-
dade. Acreditamos, com isso, que você terá seus conhecimentos consolidados.
Com certeza, sabemos que para desempenhar bem as tarefas de desenvolvedor de
software você precisa agregar muitas coisas. O conhecimento é fundamental, mas ele precisa
ser colocado em prática.
Você viu, nos estudos das unidades iniciais, quais são as características desejáveis ao perfil
do desenvolvedor de software. E, viu também, que a participação do usuário perante o desen-
volvedor é de grande importância, pois enquanto o desenvolvedor tem conhecimento da área
técnica, o usuário tem o conhecimento sobre o domínio de negócio. Portanto, além dos conhe-
cimentos técnicos, para que um sistema alcance o sucesso desejado, é de extrema importância
a presença do especialista do domínio de negócio, e ninguém melhor que o cliente/usuário para
isso.
Nesta unidade faremos uma revisão breve de cada conceito antes de colocá-lo em prática
para que você possa compreender bem cada etapa. E, fica a nossa sugestão: procure revisar
cada tópico, tentando elaborar uma solução melhor que a apresentada.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 197

É interessante colocar em prática seus conhecimentos procurando sempre conhecer no-


vas técnicas. Não esqueça que um mesmo problema pode apresentar soluções diferentes, e
as mais simples podem ser, muitas vezes, as melhores. O desenvolvimento de software requer
também criatividade do desenvolvedor.
Vamos, então, começar nossa última etapa. Bons estudos a todos!

5. DESCRIÇÃO DO SISTEMA
Trata-se de um sistema para controle de alunos de uma universidade. Um sistema aca-
dêmico para uma universidade é bastante extenso. Nosso foco será apenas nos processos rela-
cionados mais diretamente aos alunos, ou seja, cadastro de alunos, matrícula, publicação das
notas.
Para isso, consideremos uma universidade que oferece diversos cursos. Um aluno pode
cursar mais que um curso, tanto ao mesmo tempo quanto em épocas diferentes. Ao ingressar
na universidade, um cadastro do aluno é feito, com suas informações pessoais.
O aluno é admitido e, no momento da matrícula, é realizado seu cadastro. Isso acontece
apenas na primeira matrícula do aluno. Os cursos são semestrais. Assim, o aluno faz nova matrí-
cula a cada semestre, ou quando ingressa em um novo curso.
Existe um cadastro com todas as disciplinas, e também um com as disciplinas oferecidas
por semestre, para cada curso. Para cada semestre, o aluno faz uma matrícula nas disciplinas
que ele deseja cursar, e turmas são oferecidas para cada disciplina. Um professor pode ministrar
aulas em diversas disciplinas, e em cursos diferentes.
Para cada turma, é designada uma sala de aula ou laboratório, que podem ser utilizados
por diversas turmas. Disciplinas podem ter ou ser pré-requisito para/de outra disciplina. Um
aluno somente se matricula em determinada disciplina caso não haja qualquer tipo de impedi-
mento para isso.

6. REQUISITOS DO SISTEMA
O levantamento de requisitos é uma fase em que se busca, com usuários, informações so-
bre as funções e restrições impostas ao sistema que será desenvolvido. As formas de obtenção
dessas informações, conforme já estudado, são as entrevistas com os usuários, a observação de
sua rotina de trabalho, a análise de documentos e os sistemas utilizados nas atividades atuais
do usuário.
Lembramos que os requisitos podem sofrer alterações durante todo o tempo de desen-
volvimento do sistema, podendo aumentar ou diminuir o número de requisitos do sistema. No
nosso exemplo, como se trata de um sistema fictício (não temos realmente um cliente que possa
solicitar alterações nos requisitos), os requisitos levantados não sofrerão alterações no decorrer
do desenvolvimento do projeto do sistema.
Os requisitos são classificados em requisitos funcionais e requisitos não funcionais. Os re-
quisitos funcionais correspondem a todas as funcionalidades do sistema, ou seja, a tudo o que
o sistema deve fazer. E, os requisitos não funcionais correspondem às restrições sobre como o
sistema deve realizar os requisitos funcionais.
Portanto, com base na descrição do sistema, em relação às funcionalidades que o sistema de
controle de alunos de uma universidade deve ter, podemos listar os seguintes requisitos funcionais:

Claretiano - Centro Universitário


198 © Análise e Projeto de Sistemas

Requisitos funcionais – Sistema de Controle de Alunos de uma Universidade


a) RF1. O Sistema deve manter informações cadastrais sobre as disciplinas oferecidas
nos diversos cursos.
b) RF2. O Sistema deve manter informações cadastrais sobre os Professores/Coordena-
dores.
c) RF3. O Sistema deve manter informações cadastrais sobre as turmas abertas para
cada disciplina.
d) RF4. O Sistema deve manter informações cadastrais sobre as salas e os laboratórios
disponíveis para cada turma.
e) RF5. O Sistema deve manter informações cadastrais sobre os Alunos.
f) RF6. O Sistema deve permitir que Alunos façam matrícula em disciplina.
g) RF7. O Sistema deve permitir que Professores lancem as notas e faltas dos Alunos.
h) RF8. O Sistema deve permitir que Alunos visualizem as notas obtidas durante o se-
mestre, assim como o número de faltas.
i) RF9. O Sistema deve manter as informações sobre os históricos escolares dos Alunos.
j) RF10. O Sistema deve permitir que o Aluno tranque ou cancele sua matrícula a qual-
quer momento, desde que ele não tenha pendências que o impeçam de tal ato.
k) RF11. O Sistema deve manter informações sobre a grade curricular de cada curso.
l) RF12.  O Sistema deve permitir que os Coordenadores visualizem o andamento das
matrículas.
m) RF13. O Sistema deve permitir que o Professor mantenha as informações sobre o pla-
no de ensino e o plano de aulas.
n) RF14. O Sistema deve calcular a média final do Aluno.
o) RF15. O Sistema deve calcular o percentual de faltas do Aluno.
p) RF16. O Sistema deve permitir que o aluno fique em uma lista de espera quando a
disciplina por ele solicitada para matrícula não tiver mais vagas, ou não tiver número
suficiente de interessados para ser aberta.
Como forma de apresentação do documento de requisitos, utilizaremos um formulário (já
apresentado para você quando estudamos os requisitos do Sistema). Ressaltamos que os requi-
sitos funcionais podem ser classificados em evidentes ou ocultos.
Assim, a primeira versão do documento de requisitos funcionais fica:

SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE

Requisitos Funcionais
Nome: Cadastrar Cursos. Evidente/Oculto: (E)
Descrição: O Sistema deve manter informações cadastrais sobre as disciplinas oferecidas nos diversos cursos.

Nome: Cadastrar Professores/Coordenadores. Evidente/Oculto: (E)


Descrição: O Sistema deve manter informações cadastrais sobre os Professores.

Nome: Cadastrar Turmas. Evidente/Oculto: (E)


Descrição: O Sistema deve manter informações cadastrais sobre as turmas abertas para cada disciplina.

Nome: Cadastrar Salas/Laboratórios. Evidente/Oculto: (E)


Descrição: O Sistema deve manter informações cadastrais sobre as salas e os laboratórios disponíveis para cada turma.

Nome: Cadastrar Alunos. Evidente/Oculto: (E)


Descrição: O Sistema deve manter informações cadastrais sobre os Alunos.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 199

Nome: Matricular Aluno. Evidente/Oculto: (E)


Descrição: O Sistema deve permitir que Alunos façam matrícula em disciplina.

Nome: Lançar Notas e Faltas de Alunos. Evidente/Oculto: (E)


Descrição: O Sistema deve permitir que Professores lancem as notas e faltas dos Alunos.

Nome: Visualizar Notas e Faltas. Evidente/Oculto: (E)


Descrição: O Sistema deve permitir que Alunos visualizem as notas obtidas durante o semestre, assim como o número de
faltas.

Nome: Manter Controle sobre Históricos Escolares. Evidente/Oculto: (E)


Descrição: O Sistema deve manter as informações sobre os históricos escolares dos Alunos.

Nome: Trancar ou Cancelar Matrícula. Evidente/Oculto: (E)


Descrição: O Sistema deve permitir que o aluno tranque ou cancele sua matrícula a qualquer momento, desde que ele não
tenha pendências que o impeçam de tal ato.

Nome: Cadastrar Grade Curricular. Evidente/Oculto: (E)


Descrição: O Sistema deve manter informações sobre a grade curricular de cada curso

Nome: Visualizar Andamento das Matrículas. Evidente/Oculto: (E)


Descrição: O Sistema deve permitir que os Coordenadores visualizem o andamento das matrículas.

Nome: Elaborar Plano de Ensino e Planos de Aula. Evidente/Oculto: (E)


Descrição: O Sistema deve permitir que o Professor mantenha as informações sobre o plano de ensino e planos de aula.

Nome: Cálculo da Média Final. Evidente/Oculto: (O)


Descrição: O Sistema deve calcular a média final do Aluno.

Nome: Cálculo do Percentual de Faltas. Evidente/Oculto: (O)


Descrição: O Sistema deve calcular o percentual de faltas do Aluno.

Nome: Atender Lista de Espera. Evidente/Oculto: ( E)


Descrição: O Sistema deve permitir que o aluno fique em uma lista de espera quando a disciplina por ele solicitada para
matrícula não tiver mais vagas, ou não tiver número suficiente de interessados para ser aberta.

Os requisitos não funcionais podem ser classificados em várias categorias, como já foi
visto anteriormente. Dentre estas categorias temos: usabilidade, confiabilidade, performance,
configurabilidade, segurança, implementação, interface, entre outras.
Além disso, os requisitos não funcionais podem ser classificados em obrigatórios ou dese-
jáveis, e também em permanentes ou transitórios.
Os seguintes requisitos não funcionais podem ser listados, inicialmente, para o sistema de
controle de alunos de uma universidade:
SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE
Requisitos Não Funcionais
Obrigatório/Desejável (O)
Nome: Controle de Acesso.
Permanente/Transitório (P)

Claretiano - Centro Universitário


200 © Análise e Projeto de Sistemas

SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE


Requisitos Não Funcionais
Restrições:
1. As operações de cadastro de cursos, salas e
laboratórios, disciplinas, turmas e alunos somente
serão realizadas por usuários com permissão
concedida aos funcionários administrativos da
secretaria escolar.
2. As operações de cadastro de Professores
e Coordenadores somente serão realizadas
por usuários com permissão concedida aos
funcionários administrativos do departamento de
recursos humanos.
3. As operações referentes a matricula de alunos,
trancamento ou cancelamento de matrículas,
manutenção das informações geradas em históricos Categoria: Segurança
escolares apenas serão realizadas por usuários
com permissão concedida aos funcionários
administrativos da secretaria escolar.
4. Lançamentos de notas, elaboração de plano de
ensino e planos de aulas somente serão efetuados
por usuários com permissão de Professor.
5. Visualização do andamento das matrículas,
manutenção de grade curricular, abertura e
fechamento de turmas e atendimento de listas de
espera são operações realizadas por usuários com
a permissão de coordenador.
6. Aos usuários com perfil de aluno somente serão
permitidas as operações de consultas aos boletins,
planos de ensino e de aulas, grade curricular e
grade de horários.

Nome: Identificação do aluno. Obrigatório/Desejável (D)


Permanente/Transitório (P)
Restrição: O aluno será identificado por seu nome
Categoria: Interface
ou pelo número do Registro Acadêmico (RA).

Nome: Identificação do Professor/Coordenador. Obrigatório/Desejável (D)


Permanente/Transitório (P)
Restrição: O Professor/Coordenador será
identificado por seu nome ou por seu código Categoria: Interface
funcional.

Nome: Armazenamento de dados. Obrigatório/Desejável (O)


Permanente/Transitório (P)
Restrição: O Sistema deve ser desenvolvido
(camada de persistência) de forma que diferentes
Categoria: Persistência
tecnologias de banco de dados possam ser
utilizadas.

7. DOCUMENTAÇÃO DAS REGRAS DE NEGÓCIO


Uma das etapas do desenvolvimento de um sistema é a determinação das regras de ne-
gócio. Trata-se das políticas, condições ou restrições a serem consideradas para a execução do
sistema. São específicas da organização para a qual o sistema está sendo desenvolvido, pois elas
descrevem a forma como a organização funciona. E, é na fase de levantamento de requisitos que
elas são determinadas.
Depois de definidas, elas são documentadas no modelo de regras de negócio. Assim, po-
demos definir as seguintes regras de negócio para o sistema de controle de alunos de uma uni-
versidade:
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 201

a) Número máximo de alunos admitidos por turma.


b) Número máximo de créditos a serem cursados por semestre.
c) Habilitação do Professor para ministrar as aulas em um determinado curso.
d) Pré-requisitos para uma disciplina.
e) Cancelamento de matrícula.
f) Trancamento de matrícula.
g) Valor mínimo da média para aprovação do aluno.
h) Percentual mínimo de frequência para aprovação do aluno.
i) Para uma turma ser aberta, ela deve estar cadastrada no sistema.
j) Número mínimo de alunos para abertura de uma turma.
As regras de negócio podem ser acomodadas em um formulário denominado modelo de
regras de negócio. O layout deste formulário fica a critério do desenvolvedor. Deve ser simples,
apenas com as informações necessárias para a documentação.
Veja as regras de negócio do sistema acomodadas no documento:

SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE

Regras de Negócio
RN1. Número máximo de alunos admitidos por turma.
Descrição Cada turma, independentemente do curso, poderá ter, no máximo, 50 alunos.

RN2. Número máximo de créditos a serem cursados por semestre.


Descrição Um aluno pode cursar, no máximo, a quantidade de disciplinas referentes a 30 créditos por semestre.

RN3. Habilitação do Professor para ministrar as aulas em um determinado curso.


Descrição Um Professor deverá possuir, no mínimo, a titulação de especialista para ministrar aulas.

RN4. Pré-requisitos para uma disciplina.


Descrição Uma disciplina poderá ser pré-requisito para apenas uma disciplina.

RN5. Cancelamento de matrícula.


Um aluno pode cancelar sua matrícula, desde que não haja qualquer pendência referente ao período em que
Descrição
esteve matriculado.

RN6. Trancamento de matrícula.


Um aluno pode cancelar sua matrícula, desde que não haja qualquer pendência referente ao período em que
Descrição
esteve matriculado.

RN7. Valor mínimo da média para aprovação do aluno.


O valor mínimo para que um aluno esteja aprovado em uma disciplina é 6,0 (além do percentual mínimo de
Descrição
frequência).

RN8. Percentual mínimo de frequência para aprovação do aluno.


Um aluno deve ter um percentual mínimo de 75% de frequência em cada disciplina para ser aprovado (além
Descrição
do valor mínimo para a média).

RN9. Turma deve ser cadastrada antes da abertura.


Descrição Para uma turma ser aberta, ela deve estar cadastrada no Sistema.

RN10. Número mínimo de alunos para abertura de uma turma.


Descrição Uma turma deve ter um mínimo de 30 alunos para ser aberta.

Claretiano - Centro Universitário


202 © Análise e Projeto de Sistemas

8. DOCUMENTAÇÃO DO MODELO DE CASOS DE USO


A documentação dos Casos de Uso envolve identificar os atores e os Casos de Uso envol-
vidos em cada caso.
No sistema de controle de alunos de uma universidade identificamos os seguintes atores:
a) Secretaria Acadêmica: setor da universidade responsável por manter todas as infor-
mações sobre os alunos e sua vida acadêmica na universidade.
b) Sistema de Recursos Humanos: Sistema responsável por manter e fornecer informa-
ções sobre Professores/Coordenadores ao Sistema de controle de alunos de uma uni-
versidade.
c) Aluno: aquele que ingressa em um curso na universidade.
d) Professor: aquele que leciona disciplinas oferecidas nos cursos da universidade.
e) Coordenador: aquele que é responsável por manter o controle e cuidar dos assuntos
referentes a determinado curso (alunos, professores, grade curricular, planos de ensi-
no e de aulas, andamento das matrículas).
Uma vez identificados os atores que vão interagir com o Sistema, é necessário identificar
os Casos de Uso e associá-los aos atores que deles participam:
a) Cadastrar Turmas (Secretaria Acadêmica).
b) Abrir Turma (Coordenador).
c) Fechar Turma (Coordenador).
d) Inserir Informações sobre Aluno (Secretaria Acadêmica).
e) Pesquisar Informações sobre Aluno (Secretaria Acadêmica).
f) Atualizar Informações sobre Aluno (Secretaria Acadêmica).
g) Pesquisar Informações sobre Professor (Secretaria Acadêmica).
h) Pesquisar Informações sobre Coordenador (Secretaria Acadêmica).
i) Manter Informações sobre Disciplina (Secretaria Acadêmica).
j) Manter Informações sobre a Grade Curricular de Curso (Coordenador).
k) Manter Informações sobre Plano de Ensino (Professor).
l) Manter Informações sobre Plano de Aulas (Professor).
m) Manter Informações sobre Sala/Laboratório (Secretaria Acadêmica).
n) Matricular Aluno (Aluno).
o) Cancelar Matrícula (Aluno).
p) Trancar Matrícula (Aluno).
q) Lançar Notas e Faltas (Professor).
r) Visualizar Boletim (Aluno).
s) Visualizar Andamento das Matrículas (Coordenador).
t) Atender Lista de Espera (Coordenador).
Depois que os Casos de Uso foram definidos, o próximo passo é elaborar uma descrição
dos processos identificados. Os Casos de Uso que representam os processos mais complexos
merecem mais atenção, pois da descrição bem elaborada deles depende da compreensão do
processo por parte dos envolvidos com o Sistema. Portanto, não há necessidade de descrever
todos os Casos de Uso.
Apresentamos, então, a descrição de apenas alguns Casos de Uso. Como sugestão, procu-
re descrever todos os Casos de Uso. Lembre-se de que quanto mais praticar, mais fáceis essas
tarefas vão se tornando.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 203

Quando estudamos os Casos de Uso, você aprendeu que eles podem ser descritos sob
formatos diferentes. Apresentamos, naquela ocasião, o formato tabular. Neste projeto, utili-
zaremos outro formato, o sequencial. A escolha do formato de apresentação da descrição dos
Casos de Uso fica a critério do desenvolvedor da tarefa. Qualquer uma das formas apresentadas
é correta. O importante é que a descrição seja clara e colabore para a compreensão do processo
descrito.
Vamos, neste exemplo, descrever os seguintes Casos de Uso:
a) Matricular Aluno.
b) Lançar Notas e Faltas.
c) Atender Lista de Espera.
d) Visualizar Boletim.
e) Visualizar Andamento das Matrículas.
f) Abrir Turma.

Descrição dos Principais Casos de Uso do Sistema


a) Caso de Uso: Matricular Aluno.
b) Sumário: Aluno solicita matrícula em disciplina.
c) Ator Primário: Aluno.
d) Ator Secundário: Secretaria Acadêmica.
e) Pré-condições: o Aluno deve estar cadastrado no Sistema; o Aluno não pode estar
reprovado em disciplina que seja pré-requisito para a disciplina na qual deseja se ma-
tricular.

Fluxo Principal
1) O Aluno solicita realização de matrícula.
2) O Sistema apresenta a lista de disciplinas nas quais o Aluno pode se matricular (o Sis-
tema não disponibiliza para o Aluno as disciplinas que são pré-requisitos para aquelas
que ele ainda não tenha cursado ou nas quais esteja reprovado).
3) O Aluno seleciona as disciplinas que deseja cursar.
4) Para cada disciplina escolhida, o Sistema apresenta as turmas que oferecem tal disci-
plina.
5) O Aluno escolhe a turma desejada.
6) Para a turma escolhida, o Sistema informa a sala/laboratório no qual as aulas serão
ministradas, assim como o nome do Professor e os dias e os horários das aulas. A
sequência dos passos 4, 5 e 6 deve ser repetida para cada disciplina escolhida pelo
Aluno.
7) O Sistema solicita a confirmação do Aluno para as turmas escolhidas.
8) O Aluno confirma suas escolhas.
9) O Sistema registra a matrícula do Aluno nas disciplinas escolhidas.
10) O Sistema encerra a operação.
Fluxo Alternativo (4): Inclusão do Aluno em lista de espera.
a) O sistema informa que não existe turma aberta para a disciplina escolhida, ou que não
há mais vagas na turma.
b) O Sistema oferece uma lista de espera para o Aluno aguardar pela possibilidade de
abertura de turma para a disciplina escolhida.
c) Se o aluno aceitar, o sistema o insere na lista de espera. O sistema volta ao passo 4,
caso haja mais disciplinas escolhidas, ou vai para o passo 7.

Claretiano - Centro Universitário


204 © Análise e Projeto de Sistemas

d) Se o aluno não aceitar, o sistema volta ao passo 4, caso haja mais disciplinas escolhi-
das, ou vai para o passo 7.
Fluxo de Exceção (4): Violação da RN02.
a) Excesso de créditos nas disciplinas escolhidas pelo aluno para o semestre. O sistema
informa ao aluno a quantidade de créditos excedentes, para que ele possa refazer suas
escolhas. O Sistema volta ao passo 3.
Pós-condições: o aluno foi matriculado nas disciplinas selecionadas e/ou foi inscrito em
uma ou mais listas de espera.
Regras de Negócio: RN1, RN2, RN4.
Caso de Uso: lançar notas e faltas.
Sumário: Professor lança notas e faltas dos Alunos para a disciplina que ele ministrou no
período.
Ator Primário: Professor.
Ator Secundário: não há.
Pré-condições: o Professor deve estar cadastrado no sistema.

Fluxo Principal
a) O Professor solicita o lançamento de notas.
b) O Sistema apresenta a lista de disciplinas relacionadas ao Professor.
c) O Professor escolhe a disciplina para a qual as notas e faltas serão lançadas.
d) Para a disciplina escolhida, o Sistema exibe as turmas.
e) O Professor escolhe a turma para a qual fará o lançamento das notas e faltas.
f) O Sistema exibe a lista com os nomes dos Alunos matriculados na turma.
g) Para cada Aluno, o Professor lança as notas e o número de faltas no período.
h) O Sistema solicita a confirmação dos dados pelo Professor.
i) O Professor confirma os dados.
j) Para cada Aluno, o Sistema calcula a média das notas e o percentual de frequência no
período.
k) O Sistema registra os resultados.
l) O Sistema encerra a operação.
Fluxo Alternativo (9): Professor não confirma os dados digitados.
a) O Professor verifica que lançou nota ou falta errada para um ou mais alunos.
a) O Professor faz as devidas correções.
b) O Sistema registra a correção e vai para o passo 10.
Fluxo de Exceção (8): Lançamento de nota ou falta não realizada para um ou mais alunos.
a) O Sistema informa ao Professor que não houve o lançamento de nota e/ou falta para
o aluno.
b) O Professor faz o lançamento que falta.
c) O Sistema retorna ao passo 8.
Pós-condições: as notas e frequências dos alunos que cursaram uma disciplina em deter-
minada turma foram lançadas, e a média das notas, assim como o percentual de frequência para
cada aluno, no período, foram calculados e registrados.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 205

Pós-condições: o Aluno foi matriculado nas disciplinas selecionadas e/ou foi inscrito em
uma ou mais listas de espera.
Regras de Negócio: RN7, RN8.
Caso de Uso: Atender Lista de Espera.
Sumário: Coordenador cria uma turma extra para atender demanda.
Ator Primário: Coordenador.
Ator Secundário: Aluno.
Pré-condições: O Coordenador deve estar cadastrado no Sistema; deve existir uma lista de
espera com um mínimo de 30 alunos para ser atendida.

Fluxo Principal
a) Ao completar 30 alunos na lista de espera para determinada disciplina, o Sistema si-
naliza esta informação.
b) O Coordenador solicita abertura da lista sinalizada, com os nomes dos interessados
em determinada disciplina.
c) O Sistema apresenta as informações da lista solicitada.
d) O Coordenador solicita que a lista seja atendida.
e) O Sistema solicita as informações para abertura da turma extra.
f) O Coordenador informa o(s) dia(s) e horário(s) para o funcionamento da nova turma.
g) O Sistema apresenta a lista de Professores disponíveis.
h) O Coordenador seleciona o Professor.
i) O Sistema exibe as salas/laboratórios disponíveis.
j) O Coordenador seleciona a sala/laboratório.
k) O Sistema solicita confirmação dos dados informados.
l) O Coordenador confirma os dados.
m) O Sistema registra a abertura da turma extra.
n) O Sistema transfere cada Aluno da lista para a nova turma, excluindo a lista.
o) O Sistema registra as novas matrículas.
p) O Sistema envia um e-mail automático a cada Aluno informando sobre a efetivação
da matrícula.
q) O Sistema encerra a operação.
Fluxo Alternativo (7): Não há Professores disponíveis para os dias/horários informados.
a) O Sistema informa que não existe disponibilidade de Professor para os dias/horários
informados pelo Coordenador, e solicita nova entrada de dias/horários.
b) O Coordenador informa novos dias/horários. Caso haja possibilidade de Professores,
o Sistema continua no passo 9.
c) Caso não haja disponibilidade de Professores, o Sistema volta ao passo (a) deste fluxo
alternativo até que haja disponibilidade, ou o Coordenador pode solicitar ao Sistema
que cancele a lista e encerre a operação.
Fluxo Alternativo (9): não há salas/laboratórios disponíveis para os dias/horários informa-
dos.
a) O Sistema informa que não existe disponibilidade de sala/laboratório para os dias/
horários informados pelo Coordenador, e solicita nova entrada de sala/laboratório.
b) O Coordenador informa nova sala/laboratório. Caso haja possibilidade de sala/labora-
tório, o Sistema continua no passo 11.
Claretiano - Centro Universitário
206 © Análise e Projeto de Sistemas

c) Caso não haja disponibilidade de sala/laboratório, o Sistema volta ao passo (a) deste
fluxo alternativo até que haja disponibilidade, ou o Coordenador pode solicitar ao
Sistema que cancele a lista e encerre a operação.
Pós-condições: uma turma extra foi criada para determinada disciplina.
Regras de Negócio: RN1, RN9.
Caso de Uso: Visualizar Boletim.
Sumário: Aluno solicita visualização de seu boletim (notas e faltas) para o período esco-
lar.
Ator Primário: Aluno.
Ator Secundário: Não há.
Pré-condições: O Aluno deve estar cadastrado no Sistema e matriculado em disciplinas.

Fluxo Principal
a) O Aluno solicita visualização de seu boletim.
b) O Sistema exibe as notas, médias, número de faltas e percentual de frequência para
cada disciplina.
c) O Aluno visualiza as informações exibidas.
d) O Sistema encerra a operação.
Pós-condições: O boletim do Aluno foi exibido.
Caso de Uso: Visualizar Andamento das Matrículas.
Sumário: Coordenador solicita ao Sistema a visualização do andamento das matrículas nas
disciplinas que estão sendo oferecidas para o próximo semestre letivo.
Ator Primário: Coordenador.
Ator Secundário: Não há.
Pré-condições: O Coordenador deve estar cadastrado no Sistema.

Fluxo Principal
a) O Coordenador solicita ao Sistema a visualização do andamento das matrículas reali-
zadas até o momento nas disciplinas oferecidas.
b) O Sistema exibe a lista com todas as disciplinas oferecidas para o próximo semestre.
c) O Coordenador seleciona uma disciplina para a qual deseja ver o andamento das ma-
trículas.
d) O Sistema exibe a lista das turmas que foram abertas para oferecer tal disciplina.
e) O Coordenador seleciona a turma para a qual deseja ver o andamento das matrícu-
las.
f) O Sistema exibe uma lista contendo os dias e horários nos quais a disciplina será mi-
nistrada, o nome do Professor e a relação de todos os Alunos que já efetuaram suas
matrículas na referida turma.
g) O Coordenador visualiza as informações contidas na lista.
h) Caso o Coordenador deseje continuar com a visualização de outras turmas, o Sistema
retorna ao passo 4; caso contrário, o Sistema encerra a operação.
Pós-condições: Listas com matrículas realizadas até o momento foram visualizadas pelo
Coordenador.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 207

Caso de Uso: Abrir Turma.


Sumário: Coordenador abre turma para atender a demanda de Alunos em disciplinas no
próximo semestre letivo.
Ator Primário: Coordenador.
Ator Secundário: Não há.
Pré-condições: O Coordenador deve estar cadastrado no Sistema; o nome de turma deve
estar cadastrado no Sistema.

Fluxo Principal
a) O Coordenador solicita ao Sistema a relação de turmas cadastradas e ainda não aber-
tas para determinada disciplina de um curso.
b) O Sistema exibe a lista das turmas disponíveis.
c) O Coordenador seleciona uma turma para a qual deseja ofertar disciplina no próximo
semestre, referente a determinado curso sob sua coordenação.
d) O Sistema exibe a lista com os nomes dos Professores que ministram tal disciplina e
suas disponibilidades de horários.
e) O Sistema solicita a escolha de um Professor.
f) O Coordenador seleciona o Professor.
g) O Sistema solicita o(s) dia(s) e horário(s) das aulas.
h) O Coordenador informa o(s) dia(s) e horário(s) das aulas, de acordo com a disponibi-
lidade do Professor.
i) O Sistema solicita confirmação das escolhas.
j) O Coordenador confirma as escolhas.
k) O Sistema registra as informações e a turma é aberta.
l) O Sistema encerra a operação.
Fluxo Alternativo (2): Não existe turma criada para tal disciplina.
a) O Sistema informa que não existe turma criada para tal disciplina.
b) Se o Coordenador desejar que a turma seja criada, executar o Caso de Uso "Cadastrar
Turma"; caso contrário, o Sistema executa o passo 12.
Fluxo de Alternativo (6): Coordenador não escolhe Professor.
a) O Coordenador não escolhe Professor, por haver algum tipo de impedimento de dia/
horário para a abertura da turma, de acordo com as disponibilidades dos Professores
que ministram a disciplina.
b) O Sistema executa o passo 12.
Fluxo de Alternativo (10): Coordenador não confirma as escolhas.
a) O Coordenador não confirma suas escolhas.
b) Se Coordenador quiser repetir as escolhas, o Sistema retorna ao passo 2; caso contrá-
rio, o Sistema executa o passo 12.
Pós-condições: uma turma foi aberta para oferecer uma disciplina no próximo semestre
letivo.
Regras de Negócio: RN9.
Todos os diagramas que serão criados no projeto Controle de Alunos de uma Universidade
serão mostrados, passo a passo, no Tópico 14.

Claretiano - Centro Universitário


208 © Análise e Projeto de Sistemas

Diagrama de Casos de Uso


O primeiro diagrama que vamos elaborar para o nosso sistema é o Diagrama de Casos de
Uso. Ele representa, por meio de elementos gráficos definidos pela UML, os atores, os Casos de
Uso e os relacionamentos entre eles.
Para desenhar os diagramas deste sistema, utilizaremos uma ferramenta gráfica aberta,
denominada Astah Community, e que pode ser acessada por meio do endereço: <http://astah.
change-vision.com/en/product/astah-community.html>. Caso tenha alguma dificuldade, entre
em contato com seu tutor.
A Figura 1 apresenta o Diagrama de Casos de Uso para o Sistema de Controle de Alunos
de uma Universidade.

<<e
xten
d>>

Figura 1 Diagrama de Casos de Uso para o Sistema de Controle de Alunos de


uma Universidade.

9. DOCUMENTAÇÃO DO MODELO DE CLASSES


Vimos que existem três fases para o modelo de classes: o modelo de classes de análise, o
modelo de classes de projeto e o modelo de classes de implementação.
A primeira delas refere-se à modelagem conceitual de classes, cuja finalidade é descrever
as informações que o sistema vai gerenciar. É uma fase associada ao domínio do problema,
fazendo parte da fase de análise do desenvolvimento de um projeto. Nela são descobertos os
conceitos relacionados ao sistema, ou seja, quem contém as informações a serem tratadas pelo
sistema. É um modelo independente da solução física. O modelo de classes de análise é repre-
sentado pelo Diagrama de Classes da UML, e tem três elementos que representam a informa-
ção: conceitos, atributos e associações.
Conforme já visto anteriormente, este modelo pode ser obtido pela análise dos Casos de
Uso. Por meio de cada caso de uso, é possível identificar quais classes são necessárias para ob-
tenção dos resultados externamente visíveis.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 209

Observemos como fazer para descobrir os elementos do modelo conceitual:


• Identificamos, nos Casos de Uso, palavras que correspondam a conceitos sobre os quais
desejamos manter informações no sistema.
• Identificamos e agrupamos palavras que são sinônimos.
• Procuramos, dentre as palavras identificadas, separar aquelas que são atributos, das
que são conceitos.
Revendo os Casos de Uso do Sistema de Controle de Alunos de uma Universidade, pode-
mos, inicialmente, identificar os seguintes conceitos:
a) Curso;
b) Disciplina;
c) Grade Curricular;
d) Turma;
e) Plano de Ensino;
f) Plano de Aulas;
g) Lista de Espera;
h) Sala/Laboratório;
i) Coordenador;
j) Professor;
k) Aluno;
l) Boletim.
Você deve estar lembrado que, apesar de conseguirmos identificar alguns conceitos dire-
tamente nos Casos de Uso, nem sempre o diagrama é construído apenas com estes conceitos.
Vejamos, na Figura 2, o Diagrama de Classes em sua primeira versão (consulte o tutorial do tó-
pico 14, para acompanhar o passo a passo da construção do diagrama).

Figura 2 Diagrama de Classes para o Sistema de Controle de Alunos de uma Universidade.

Claretiano - Centro Universitário


210 © Análise e Projeto de Sistemas

Note que temos, nesse diagrama, uma classe associativa chamada ItemMatricula. Essa
classe contém informações das duas classes às quais ela está relacionada, isto é, as classes Ma-
tricula e DisciplinaOfertada.
Imagine um aluno cursando seis disciplinas no semestre de determinado curso. A classe
Matricula deve conter informações como o nome do aluno, o ano e o semestre da matrícula, o
curso etc. Na classe DisciplinaOfertada temos informações sobre cada disciplina que está sen-
do oferecida no semestre. A classe associativa ItemMatricula deve conter informações como o
nome do aluno e a disciplina que ele está cursando (atualmente matriculado) ou, inclusive, as
disciplinas que ele já tenha cursado. Portanto, é nesta classe que conseguimos perceber quais
são todas as disciplinas nas quais o aluno já esteve ou encontra-se matriculado em determinado
curso.
Outra classe associativa é a classe Ministra. Ela está associada às classes DisciplinaOfer-
tada e ProfessorDisc. Esta classe deve conter informações que nos permitem responder, por
exemplo, à seguinte questão: "Quais são as disciplinas ministradas por determinado professor
no semestre corrente?". Ou também: "Quais disciplinas determinado professor ministrou no
semestre anterior?", além de outras.
Temos, ainda, uma classe chamada ItemLista conectada à classe ListaEspera por meio de
uma associação do tipo composição. Significa que a classe ListaEspera pode conter informações
sobre o número de uma lista, a quantidade de alunos inscritos nela e o nome da disciplina para
a qual a lista foi aberta. E em ItemLista podem constar informações relacionadas ao aluno que
tem interesse na matrícula na referida disciplina.

10. GLOSSÁRIO
O glossário é a relação dos termos relevantes do domínio do sistema. No nosso caso, os
termos relacionados ao domínio da universidade. Eles podem ser termos relacionados às clas-
ses do sistema, a palavras utilizadas pelos usuários, ou qualquer outro tipo de termo que esteja
relacionado ao domínio e ao qual se queira associar um tipo de definição.
Sugere-se que os termos relacionados apareçam em ordem alfabética, para facilitar a bus-
ca por seus significados.
O glossário pode ser atualizado constantemente, enquanto o sistema estiver em desenvol-
vimento. Conforme os termos vão surgindo, eles podem ser acrescentados.
Inicialmente, são estes os termos definidos para o glossário do Sistema de Controle de
Alunos de uma Universidade:
a) Aluno: pessoa que faz matrícula em determinado curso.
b) Coordenador: pessoa responsável pela coordenação de um curso. Cabe ao coorde-
nador as tarefas de contratação de professores, abertura de turmas, manutenção de
grades de horário, compras de equipamentos para laboratórios, compra de livros téc-
nicos e acompanhamento do andamento do curso.
c) Curso: instrumento para a formação profissional. Oferecido pela universidade, é com-
posto por disciplinas inter-relacionadas, que devem ser cumpridas em determinado
tempo.
d) Secretaria Acadêmica: departamento da universidade responsável por manter as in-
formações relacionadas aos alunos e professores atualizadas, providenciar e fornecer
documentos para alunos, manter os registros de notas e situação acadêmica de cada
aluno.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 211

e) Disciplina: componente da grade curricular de um curso. Mesmo que presente em


vários cursos, tem seu conteúdo específico a cada um. Pode ser ministrada por mais
de um professor do mesmo curso.
f) Disciplina Ofertada: trata-se das disciplinas que são oferecidas em determinado se-
mestre.
g) Lista de Espera: lista na qual os alunos se inscrevem, interessados em uma disciplina
para a qual ainda não foi aberta turma, mas que pode vir a existir como turma, caso
haja um número mínimo de 30 alunos interessados.
h) Matrícula: corresponde à inscrição de um aluno em determinadas disciplinas ofereci-
das em um curso.
i) Ministrar: lecionar uma determinada disciplina.
j) Plano de Aula: relação das tarefas a serem cumpridas em cada aula de determinada
disciplina de um curso.
k) Plano de Ensino: plano elaborado para o cumprimento de tarefas relacionadas a uma
disciplina de um curso em particular.
l) Professor: pessoa responsável por ministrar aulas de determinadas disciplinas às tur-
mas de um curso. Ele deve seguir o plano de aulas por ele mesmo elaborado e avaliar
o aluno no conteúdo ministrado.
m) Registro de Notas: corresponde ao boletim do aluno, com suas notas, faltas, média e
percentual de frequência.
n) Sala/Laboratório: local da universidade onde ocorrem as aulas teóricas e práticas de
uma disciplina.
o) Turma: representa um grupo de alunos que cursa determinada disciplina de um curso,
na mesma sala, mesmo dia e horário.

11. DOCUMENTAÇÃO DO MODELO DE INTERAÇÕES


A modelagem de interações tem um papel de extrema importância no sistema, pois ela
completa aquilo que falta no modelo de Casos de Uso e no modelo de classes.
O modelo de interações representa as mensagens trocadas entre os objetos para a execu-
ção dos cenários dos Casos de Uso que foram levantados para o sistema. Nesta fase há a conso-
lidação do entendimento sobre o sistema, pois somente depois que os diagramas que compõem
este modelo são construídos para os cenários dos Casos de Uso, é que se tem clareza sobre as
responsabilidades que os objetos devem cumprir.
O modelo de interações destaca os diagramas de sequência e os diagramas de comunica-
ção. Faremos, para dar continuidade ao projeto do nosso sistema, os diagramas de sequência,
pois estes são os mais utilizados.
Para a criação dos diagramas de sequência, devemos observar os seguintes passos:
a) Preparar pelo menos um cenário para cada Caso de Uso. Vamos considerar, para nosso
sistema, o fluxo principal de cada caso de uso descrito, pois estes foram considerados
os mais relevantes ao processo como um todo.
b) Lembrar que os diagramas de sequência mostram claramente a contribuição de cada
ator, e isso leva à compreensão sobre o comportamento dos objetos.
c) Dividir as interações complexas, de forma que, para cada interação desmembrada,
seja construído um diagrama de sequência.
d) Se for necessário para colaborar com a compreensão do processo, prepare um diagra-
ma de sequência para cada condição de erro.

Claretiano - Centro Universitário


212 © Análise e Projeto de Sistemas

Os Casos de Uso descritos foram:


a) Matricular Aluno.
b) Lançar Notas e Faltas.
c) Atender Lista de Espera.
d) Visualizar Boletim.
e) Visualizar Andamento das Matrículas.
f) Abrir Turma.
Para cada caso de uso vamos extrair o fluxo principal dele, e o diagrama de sequência terá
esse fluxo como base. Veja o tutorial sobre a construção dos diagramas de sequência no Tópico
14 desta unidade.
O fluxo principal para o caso de uso Matricular Aluno é:

Matricular Aluno
a) O Aluno solicita realização de matrícula.
b) O Sistema apresenta a lista de disciplinas nas quais o Aluno pode se matricular (o Sis-
tema não disponibiliza para o Aluno as disciplinas que são pré-requisitos para aquelas
que ele ainda não tenha cursado ou nas quais esteja reprovado).
c) O Aluno seleciona as disciplinas que deseja cursar.
d) Para cada disciplina escolhida, o Sistema apresenta as turmas que oferecem tal disci-
plina.
e) O Aluno escolhe a turma desejada.
f) Para a turma escolhida, o Sistema informa a sala/laboratório onde as aulas serão minis-
tradas, assim como o nome do Professor e os dias e os horários das aulas. A sequência
dos passos 4, 5 e 6 deve ser repetida para cada disciplina escolhida pelo Aluno.
g) O Sistema solicita a confirmação do Aluno para as turmas escolhidas.
h) O Aluno confirma suas escolhas.
i) O Sistema registra a matrícula do Aluno nas disciplinas escolhidas.
j) O Sistema encerra a operação.
Podemos identificar as seguintes classes envolvidas:
AlunoCurso
DisciplinaOfertada
Turma
Matricula
ItemMatricula
O diagrama de sequência para este cenário pode ser visto na Figura 3:
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 213

Figura 3 Diagrama de Sequência para o fluxo principal do caso de uso Matricular Aluno.

Vamos elaborar o diagrama de sequência para o fluxo principal do caso de uso Lançar No-
tas e Faltas. O fluxo principal dele contém os seguintes passos:

Lançar Notas e Faltas


a) O Professor solicita o lançamento de notas.
b) O Sistema apresenta a lista de disciplinas relacionadas ao Professor.
c) O Professor escolhe a disciplina para a qual as notas e faltas serão lançadas.
d) Para a disciplina escolhida, o Sistema exibe as turmas.
e) O Professor escolhe a turma para a qual fará o lançamento das notas e faltas.
f) O Sistema exibe a lista com os nomes dos Alunos matriculados na turma.
g) Para cada Aluno, o Professor lança as notas e o número de faltas no período.
h) O Sistema solicita a confirmação dos dados pelo Professor.
i) O Professor confirma os dados.
j) Para cada Aluno, o Sistema calcula a média das notas e o percentual de frequência no
período.
k) O Sistema registra os resultados.
l) O Sistema encerra a operação.
As classes identificadas neste caso de uso são:
ProfessorDisc
DisciplinaOfertada
Turma
RegistroNotas

Claretiano - Centro Universitário


214 © Análise e Projeto de Sistemas

O diagrama de sequência para este cenário pode ser visto na Figura 4:

Figura 4 Diagrama de Sequência para o fluxo principal do caso de uso Lançar Notas e Faltas.

12. DOCUMENTAÇÃO DO MODELO DE CLASSES DE PROJETO


Vimos no Tópico 9 a documentação do modelo de classes de análise. Neste tópico vamos
ver o modelo criado na fase de análise ser transformado no modelo de classes de projeto. As
transformações e os refinamentos nas classes de análise imprimem mais rigor ao diagrama de
classes. Isso pode acontecer, por exemplo, pela definição dos tipos de atributos, além de novos
conceitos que podem surgir nesta fase e que se fazem necessários no diagrama.
Classes de fronteira servem para captar informações para o sistema e devolvê-las depois
de processadas, ou seja, são responsáveis pela comunicação com o ambiente do sistema. A elas,
portanto, não atribuímos responsabilidades relacionadas à lógica de negócio.
As classes de controle referem-se aos objetos da aplicação, e não do domínio do sistema,
e sua função é a de coordenar a interação entre os objetos. Podem ser mais bem observadas
nos diagramas de sequência (porém, não é necessário que elas apareçam nesses diagramas).
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 215

Normalmente são canais de comunicação entre os objetos das classes de fronteira e os objetos
das classes de entidade.
E, finalmente, temos as classes de entidade, nosso maior objetivo na obtenção do modelo
de classes de projeto. Elas representam os conceitos do domínio do sistema, representando as
informações que o sistema deve manipular e armazenar. São as classes do negócio. No momen-
to das transformações, as classes de entidade normalmente permanecem, pois quase sempre
geram objetos que devem ser persistentes.
Este modelo está diretamente relacionado com o modelo de implementação. Portanto,
deve definir os atributos, operações e os parâmetros que serão utilizados na implementação.
Veja, no tópico 14, como adicionar atributos e operações nas classes.

13. DOCUMENTAÇÃO DO MODELO DE ATIVIDADES


Estudamos que o Diagrama de Atividades é um tipo especial de Diagrama de Estados. Ele
representa os estados de uma atividade. Os procedimentos que ocorrem quando um Caso de
Uso é realizado são divididos em atividades, e podem ser representados por um diagrama de
atividades. Este diagrama auxilia na compreensão do comportamento do sistema no decorrer
dos Casos de Uso.
Como o processo de matrícula é o mais importante no Sistema de Controle de Alunos de
uma Universidade, apresentamos, na Figura 5, o diagrama de atividades que o representa. Veja,
no Tópico 14, o passo a passo para a construção deste diagrama.

Figura 5 Diagrama de Atividades – Matricular Aluno.

Claretiano - Centro Universitário


216 © Análise e Projeto de Sistemas

14. TUTORIAL – ASTAH COMMUNITY


Este tópico apresenta um tutorial sobre o software Astah Community. Vamos apresentar,
passo a passo, como você pode obtê-lo e como fazer para desenhar cada diagrama que utiliza-
remos no Sistema de Controle de Alunos de uma Universidade.

Acessando o Software Astah Community


No browser instalado em seu computador, digite o seguinte endereço: <http://astah.chan-
ge-vision.com/en/product/astah-community.html>.
Surgirá a seguinte tela, que pode ser observada na Figura 6:

Figura 6 Tela de acesso ao software Astah Community.

Como você pode observar, há uma opção para você fazer o download da ferramenta (con-
forme destacado em vermelho), gratuitamente. Você deve clicar nessa opção e o software será
"baixado" em sua máquina.
Depois da instalação, você deve acessá-lo para iniciar seus trabalhos com a ferramenta.

Iniciando a utilização da ferramenta Astah Community


Abra a ferramenta, clicando sobre o ícone que apareceu em sua tela após a instalação
(Figura 7), e que permite que você inicie o uso da ferramenta:

Figura 7 Ícone para iniciar o uso do Astah


Community.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 217

Surge a seguinte tela, conforme você pode observar na Figura 8:

Figura 8 Tela de abertura da ferramenta Astah Community.

Na barra de menus, clique sobre a opção File/New, ou então no botão Create a new file
(primeira opção à esquerda na barra de ferramentas). Surge a tela mostrada na Figura 9:

Figura 9 Tela de um novo projeto da ferramenta Astah Community.

Claretiano - Centro Universitário


218 © Análise e Projeto de Sistemas

Antes de iniciar os diagramas, você pode salvar o projeto em uma pasta na sua mídia.
Para isso, clique sobre o menu File/Save As. Essa operação pode ser observada na Figura 10:

Figura 10 Tela de um novo projeto da ferramenta Astah Community.

Depois, escolha o local onde vai gravar o projeto. Dê um nome a ele e pressione o botão
Save. Veja nossa sugestão, mostrada na Figura 11:

Figura 11 Nomeando um novo projeto criado na ferramenta Astah Community.


© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 219

Observe, do lado esquerdo, assim também como na barra de títulos, que aparece agora o
nome do novo projeto, conforme é mostrado na Figura 12:

Figura 12 Nome do novo projeto.

Diagrama de Casos de Uso


O primeiro diagrama a ser elaborado é o Diagrama de Casos de Uso. Na barra de menus,
selecione a opção Diagram/UseCase Diagram. Observe o menu com todos os nomes dos diagra-
mas que podem ser elaborados com a ferramenta.

Figura 13 Menu com os nomes dos diagramas da UML.

Claretiano - Centro Universitário


220 © Análise e Projeto de Sistemas

Observe, na Figura 13, a área de trabalho na qual será desenhado o Diagrama de Casos de
Uso. Ela apresenta uma barra de ferramentas com todos os botões que representam os compo-
nentes deste diagrama. Vamos começar desenhando os atores que interagem diretamente com
o sistema.
De acordo com os Casos de Uso identificados, os seguintes atores vão interagir diretamen-
te com o sistema:
a) Secretaria Acadêmica.
b) Coordenador.
c) Professor.
d) Aluno.
Para desenhar um ator, selecione o botão Actor na barra de ferramentas. Posicione o mouse
na área de trabalho e clique sobre ela. Aparece o ícone com a representação do ator e o nome
sugerido para ele: Actor1. Se você quiser que este nome permaneça para este ator, o próximo ator
terá o mesmo nome na sequência 2, 3, e assim por diante. Normalmente, queremos que o nome
nos remeta à figura do ator, conforme ele aparece no sistema.
Portanto, mudaremos o nome dos atores do nosso diagrama. Para isso, basta você digitar
o novo nome, enquanto está no modo de edição (em azul). Caso ele tenha saído do modo de
edição, basta dar um clique duplo em cima do nome, que ele entra em modo de edição nova-
mente. Ou, ainda, observe o lado esquerdo inferior na sua tela. Há um campo chamado Name.
Troque o nome do ator, sugerido pela ferramenta, para o nome desejado.
Assim desenharemos os quatro atores, e renomearemos todos eles. Veja, na Figura 14,
como fica:

Figura 14 Atores do Sistema de Controle de Alunos de uma Universidade.

Observe que você pode ir desenhando e, a qualquer momento, mover os ícones de um


lugar para outro, com facilidade. Basta clicar sobre ele a arrastar para o local desejado.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 221

O próximo passo é desenhar os Casos de Uso. Para isso, selecione o botão UseCase. Pro-
ceda da mesma forma para nomear os Casos de Uso. Façamos um desenho para cada caso de
uso identificado para o sistema.
Você deve observar que, embora tenhamos identificado vinte Casos de Uso, foram descritos
apenas os mais importantes. Observe, na Figura 15, parte do Diagrama de Casos de Uso para o
sistema estudado.
São eles:
a) Cadastrar Turmas (Secretaria Acadêmica).
b) Abrir Turma (Coordenador).
c) Fechar Turma (Coordenador).
d) Inserir Informações sobre Aluno (Secretaria Acadêmica).
e) Pesquisar Informações sobre Aluno (Secretaria Acadêmica).
f) Atualizar Informações sobre Aluno (Secretaria Acadêmica).
g) Pesquisar Informações sobre Professor (Secretaria Acadêmica).
h) Pesquisar Informações sobre Coordenador (Secretaria Acadêmica).
i) Manter Informações sobre Disciplina (Secretaria Acadêmica).
j) Manter Informações sobre a Grade Curricular de Curso (Coordenador).
k) Manter Informações sobre Plano de Ensino (Professor).
l) Manter Informações sobre Plano de Aulas (Professor).
m) Manter Informações sobre Sala/Laboratório (Secretaria Acadêmica).
n) Matricular Aluno (Aluno).
o) Cancelar Matrícula (Aluno).
p) Trancar Matrícula (Aluno).
q) Lançar Notas e Faltas (Professor).
r) Visualizar Boletim (Aluno).
s) Visualizar Andamento das Matrículas (Coordenador).
t) Atender Lista de Espera (Coordenador).

Depois de desenhar os Casos de Uso, você deve associá-los aos atores que interagem di-
retamente com eles. A Figura 15 mostra parte do diagrama de Casos de Uso. Entretanto, você
pode vê-lo na íntegra, na Figura 1.

Figura 15 Tela com parte do Diagrama de Casos de Uso.

Claretiano - Centro Universitário


222 © Análise e Projeto de Sistemas

Diagrama de Classes
Dando continuidade ao projeto do Sistema de Controle de Alunos de uma Universidade,
vamos agora à fase da construção do modelo inicial de classes, ou seja, o modelo conceitual. A
tela de abertura do Diagrama de Classes pode ser observada na Figura 16.
Selecione o menu Diagram/Class Diagram. Surge a seguinte tela:

Figura 16 Tela de abertura do Diagrama de Classes.

Começamos com o desenho da classe. Para isso, selecione o botão Class na barra de
ferramentas. Clique sobre a área de trabalho. Surge o ícone que representa uma classe. Ob-
serve, na Figura 17, a representação de uma classe. É recomendável que o nome sugerido seja
trocado por um que represente a classe desejada.

Figura 17 Representação de uma classe.


© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 223

Desenhe todas as classes identificadas. O próximo passo é desenhar as conexões entre


elas. Observe, na Figura 18, os botões da barra de ferramentas. Existe um botão que representa
uma associação simples. Ao lado desse botão existe uma seta. Se você clicar nela, aparecerão
os demais botões relacionados aos outros tipos de associação (agregação e composição). Veja
na próxima figura.
2 5 3 4

Figura 18 Botões de relacionamentos.

1 Associações por agregação e composição.


2 Associação.
3 Generalização.
4 Dependência.
Note, também, que outro elemento utilizado foi a classe de associação. Para representá-la
você deve utilizar o botão indicado pelo número 5, conforme mostra a figura anterior.
5 Classe de associação.
Depois que as classes e seus relacionamentos estão representados, é necessário acres-
centar as multiplicidades e os nomes dos relacionamentos. Para isso, posicione o mouse sobre a
linha que representa o relacionamento e clique com o botão direito.

Figura 19 Adicionando multiplicidades e nome aos relacionamentos.

Claretiano - Centro Universitário


224 © Análise e Projeto de Sistemas

Conforme mostra a Figura 19, aparece um menu. Para adicionar multiplicidades, basta
você posicionar o mouse em Multiplicity, e depois escolher uma das opções de multiplicidade
oferecidas. Para adicionar um nome ao relacionamento, posicione o mouse na primeira opção
do menu, Set Name, clique e escreva o nome que queira atribuir a ele.
Diagrama de Sequência
A próxima etapa consiste na elaboração dos diagramas de sequência. Vejamos a cons-
trução para o diagrama que corresponde ao fluxo principal do caso de uso Matricular Aluno. A
Figura 20 mostra a tela para a construção do Diagrama de Sequência.
Na barra de menus, selecione o menu Diagram/Sequence Diagram. Surgirá a seguinte tela:

Figura 20 Tela para construir o diagrama de sequência.

O próximo passo consiste em desenhar todas as classes envolvidas no processo. Para isso,
selecione o botão Lifeline. Elas devem ficar dispostas lado a lado, conforme mostra a Figura 21.
Observe qual é o ator que interage diretamente com o caso de uso. Neste caso, o ator é o
Aluno. Para representá-lo, selecione a seta ao lado do botão Lifeline. Escolha, agora, o ícone que
representa o ator, Lifeline(Actor).
Entre o ator e as classes, vamos inserir uma classe de fronteira, pela qual o ator insere as
informações ao sistema, e este devolve as mensagens. Para isso, utilize a mesma seta e escolha
o ícone Lifeline(Boundary). Como sugestão, a classe de fronteira pode ter seu nome iniciado pela
letra "I", para indicar que se trata de uma classe de interface.
Para iniciar os fluxos de mensagens, observe a sequência de passos descrita no fluxo prin-
cipal do Caso de Uso. A sequência deste fluxo está representada no diagrama. Neste diagrama
foram utilizadas as setas de mensagens síncronas e mensagens de retorno.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 225

Apresentamos o diagrama na ferramenta Astah. Você pode vê-lo na íntegra no Tópico 10.

Figura 21 Tela com visão parcial do diagrama de sequência (Matricular Aluno).

Observe que do lado esquerdo inferior da tela aparece uma guia de nome Base. Há dois
campos: Name, em que você pode nomear o diagrama em questão. Note que há um nome suge-
rido para ele. O segundo campo é o Argument. Trata-se do argumento que pode ser colocado no
nome do diagrama. Caso exista esse argumento, ele aparecerá dentro dos parênteses no nome
do diagrama.
Há, ainda, uma lista com opções que podem ser assinaladas ou não. Por exemplo, o pri-
meiro campo permite que o número que representa o índice da mensagem enviada por um ob-
jeto a outro apareça ou não. No diagrama mostrado na figura anterior, perceba que os números
correspondentes aos índices das mensagens não aparecem. A opção está desabilitada.
Para cada objeto inserido no diagrama, quando você o seleciona, uma lista com as opções
de configuração para esse objeto se abre do lado esquerdo inferior da tela, e você pode alterar
as opções inicialmente sugeridas. A tela de opções para um objeto selecionado apenas é dife-
rente da tela que aparece quando se trata do diagrama todo (explicada anteriormente).
Experimente selecionar uma classe apenas. Veja que aparece uma opção chamada Properties,
que são as propriedades para o controle selecionado. Quando você clica nesta opção, uma janela de
propriedades é aberta, com várias guias. Uma atenção especial deve ser dada à opção Stereotype. Ela
permite que você crie um estereótipo para o objeto selecionado.

Adicionando atributos e operações às classes no diagrama de classes


Para refinar o modelo de classes, você deve observar as classes definidas no modelo de
análise. Aquelas que contêm objetos que são persistentes merecem atenção nesta fase. Adicio-
naremos os atributos e as operações a elas.

Claretiano - Centro Universitário


226 © Análise e Projeto de Sistemas

Para isso, selecione a classe para a qual deseja inserir os atributos. Observe o lado esquer-
do inferior da tela. Veja que aparecem várias guias. Selecione a guia Attribute. Selecione o botão
Add, para adicionar os atributos.
No primeiro campo você deverá colocar o nome do atributo. No segundo campo você
escolherá, a partir de uma lista oferecida, o tipo do atributo. E, no quarto campo, você deverá
preencher a visibilidade. Veja na Figura 22.

Figura 22 Adicionando atributos à classe AlunoCurso.


© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 227

Depois de inserir os atributos, você deve inserir as operações. Escolha a guia Operation e,
depois, o botão Add. No primeiro campo você deverá escrever o nome da operação. No segundo
campo, deve ser escolhido o tipo de valor que será retornado pela função. E, no quarto campo,
você deve escolher a visibilidade.
Veja, na Figura 23, como fica o preenchimento:

Figura 23 Adicionando operações à classe AlunoCurso.

Claretiano - Centro Universitário


228 © Análise e Projeto de Sistemas

Diagrama de Atividades
Para elaborar o diagrama de atividades, na barra de menus escolha a opção Diagram/Ac-
tivity Diagram. Surge a seguinte tela, que pode ser observada na Figura 24:

Figura 24 Tela do diagrama de atividades.

Para iniciar o desenho do diagrama, na barra de ferramentas selecione o botão InitialNode.


É o botão que mostra o estado inicial das atividades.
Em seguida, selecione o botão Action, para desenhar a representação de uma atividade. Para
conectar os símbolos do nó inicial com a atividade, selecione o botão ControlFlow/ObjectFlow. A
cada nova atividade, repita o procedimento.
Para desenhar o símbolo que representa uma tomada de decisão, selecione o botão Decision
Node & Merge Node. A barra de bifurcação é obtida selecionando-se o botão ForkNode, e a barra de
junção é obtida selecionando-se o botão JoinNode. A Figura 25 mostra uma visão parcial do diagra-
ma de atividades Matricular Aluno.
© U8 – Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade 229

Figura 25 Visão parcial do diagrama de atividades – Matricular Aluno.

15. QUESTÃO AUTOAVALIATIVA


Esta unidade é um pouco diferente das demais, uma vez que ela abrange tudo o que você
estudou sobre análise e projeto orientados a objetos. Contém um exemplo de um sistema em
que cada etapa foi desenvolvida com explicações e o uso de uma ferramenta de modelagem.
1) Para que você faça uma autoavaliação relacionada ao conteúdo da unidade, desenvolva, com base no sistema
utilizado como exemplo, a análise e o projeto de um sistema para controlar o tempo de permanência de um
hóspede em um hotel. O sistema deve abranger desde o momento em que o cliente faz sua reserva (por telefo-
ne, por exemplo), até o momento em que ele solicita o encerramento de sua conta. O sistema deve manter as
informações cadastrais e também as informações sobre a permanência do hóspede no hotel (gastos com diárias
e serviços). Não se esqueça de que o cliente pode, também, cancelar sua reserva antes de se hospedar.

16. CONSIDERAÇÕES
Esta unidade apresentou uma visão prática da modelagem de um sistema, por meio de
um estudo de caso sobre um Sistema de Controle de Alunos de uma Universidade, com foco no
processo de matrículas.
Você acompanhou o desenvolvimento dos principais diagramas com o auxílio da ferra-
menta aberta Astah Community.
Claretiano - Centro Universitário
230 © Análise e Projeto de Sistemas

Ficam aqui algumas sugestões para melhorar o seu estudo:


• Elaboramos dois diagramas de sequência. Procure construir outros, com base nos di-
versos cenários dos Casos de Uso descritos.
• Nosso objetivo aqui não é ensinar a implementar. Entretanto, você pode prosseguir
com o projeto arquitetural do software, e implementá-lo, utilizando os conhecimentos
adquiridos no decorrer do seu curso. Para isso, reveja a Unidade 7 e busque comple-
mentar seus estudos utilizando os livros indicados na bibliografia.
Com este estudo você teve a oportunidade de compreender que o desenvolvimento de
projetos de sistemas de software não é uma tarefa simples e, dessa forma, você pôde perceber
que analisar e projetar sistemas requer muito conhecimento, bom senso, criatividade, organiza-
ção e muita prática.
Neste Caderno de Referência de Conteúdo você estudou duas abordagens de desenvolvi-
mento de software: a análise essencial e a orientação a objetos. Esta última é uma realidade
cada vez mais presente nas organizações e, caso você siga a trajetória do desenvolvimento, cer-
tamente será questionado sobre essa abordagem.
As fases de análise e projeto de sistemas são as mais importantes dentro do ciclo de vida
de um sistema, pois elas constituem a base para a sua correta implementação. Qualquer erro
cometido aqui é refletido no sistema.
Portanto, certifique-se de ter compreendido bem o conteúdo estudado e exercite-se. Nos-
sa sugestão para você é que pratique ao máximo as tarefas de análise e projeto de sistemas em
tarefas básicas do seu dia a dia.

17. REFERÊNCIAS BIBLIOGRÁFICAS


BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. 3. reimpr. Rio de Janeiro: Elsevier, 2004.

Você também pode gostar