Uma Abordagem para a Construção de Diagramas da

UML Concomitante à Prototipação de Interface

Rodrigo M. Bacurau, Brauliro G. Leal, Ricardo A. Ramos

Colegiado de Engenharia da Computação – Universidade Federal do Vale do São

Francisco (UNIVASF)
CEP 48.902-300 – Juazeiro – BA – Brasil
{rodrigo.bacurau, brauliro.leal ricardo.aramos}@univasf.edu.br

Abstract. Nowadays the Object Oriented Programming (OOP) paradigm is

the most widely used. The features of OOP, UML and development process,
allow to model and develop software more efficiently and with better quality.
However many students of information systems, computer science, computer
engineering and related, have difficulties in the construction of UML
diagrams. We propose an approach to guide the development of use case ,
class and sequence diagrams for a information system supported by the
prototype interface. A system for student library is used as a case study to
illustrate the application of the proposed approach.

Resumo. A Programação Orientada a Objetos (POO) é o paradigma mais

usado atualmente. Os recursos da POO, da UML e dos processos de
desenvolvimento, permitem modelar e desenvolver software com maior
eficiência e qualidade. No entanto muitos alunos dos cursos de sistemas de
informação, ciência da computação, engenharia da computação e afins,
encontram dificuldades na construção de diagramas da UML. Neste artigo é
proposta uma abordagem para orientar o desenvolvimento dos diagramas de
caso de uso, de classe e de sequência para um projeto de sistema de
informação em apoiado pelos protótipos de interface. Um sistema para
biblioteca estudantil é utilizado como exemplo para ilustrar a aplicação da
abordagem proposta.

1. Introdução
Produzir software de qualidade, com custo e prazos reduzidos deixou de ser desejável e
passou a ser uma necessidade. Diversas técnicas, metodologias e ferramentas vêm sendo
propostas com o intuito de dar suporte e auxiliar a produção de software de qualidade.
Um dos mais importantes avanços na comunidade de engenharia de software foi o
surgimento da Linguagem de Modelagem Unificada (UML, Unified Modeling
Language) (BOOCH et al., 2000).
A UML é uma linguagem visual que permite modelar sistemas dos mais
diversos tipos e arquiteturas, utilizando o paradigma de orientação a objetos (OMG,
2011; RAMOS, 2006). A UML é um conjunto de diagramas que representam visões
parciais do sistema, juntos estes diagramas buscam definir o sistema como um todo
(OMG, 2011; BOOCH et al., 2000).
 Apesar do grande poder de representatividade da UML, o conhecimento dessa
linguagem por si só não garante sucesso no processo de modelagem de sistemas. A
UML não consiste em um método para desenvolvimento de software, não descreve os
passos que se deve seguir para modelar um sistema. Esta linguagem limita-se,
exclusivamente, a representar o software durante toda a fase de desenvolvimento e em
diferentes níveis de abstração. Portanto recomenda-se a utilização de um processo de
desenvolvimento uniformizado, que quando aplicado corretamente em conjunto com
uma linguagem de modelagem, como a UML, resulta em um software de melhor
qualidade (ANDRETO et al, 2006).
Um processo de desenvolvimento de software consiste em um conjunto de
técnicas e metodologias que guiam o processo de concepção de sistemas de informação
(SOMMERVILLE, 2003). Grande parte dos processos de software utilizam a UML
como linguagem de modelagem. Vários modelos de processo de software foram
propostos, tais como: RUP (Rational Unified Process) (KRUCHTEN, 2003), XP
(Extreming Programing) (BECK 1999) e Catalysis (D’SOUZA et al., 1999). De acordo
com o tipo de aplicação um modelo pode ser mais adequado do que outro.
Muitos dos problemas associados ao processo de desenvolvimento de software
iniciam-se na fase de análise de requisitos (SANTANDER; CASTRO, 2000).
Requisitos mal definidos (inconsistentes) ou incompletos resultam em um produto final
que não atendem as necessidades dos usuários, pois é a partir dos requisitos que se
implementa o sistema requerido. Levantar as características e as funcionalidades que
são realmente relevantes para os usuários não é uma tarefa simples. De acordo com
Santander e Castro (2000), a dificuldade na definição de requisitos se deve
principalmente a dois fatores: a dificuldade da comunicação entre o usuário e o
desenvolvedor e o fato dos clientes não saberem o que realmente desejam do sistema.
Considerando o exposto, propõe-se neste artigo uma abordagem para auxiliar o
desenvolvimento das fases iniciais de um projeto de software, sobretudo a análise de
requisitos. Este conjunto de técnicas provê suporte a construção dos diagramas de caso
de uso concomitantemente aos protótipos de interface, os quais por sua vez dão suporte
ao desenvolvimento dos diagramas os classe e sequência de forma sistemática. Apesar
de propor um conjunto de técnicas para auxiliar o desenvolvimento de alguns diagramas
da UML, não objetiva-se neste trabalho apresentar um novo processo de software; e sim
apresentar um conjunto de técnicas que podem ser adaptadas nas primeiras fases dos
processos já existentes. Acredita-se que a aplicação destas técnicas torne o processo de
construção dos diagramas da UML mais rápido e fácil e com qualidade, de forma que
os diagramas resultantes sejam coerentes e coesos.
O restante deste artigo esta organizado da seguinte forma: na Seção 2 é
apresentada uma breve descrição da UML; na Seção 3 são apresentados os principais
conceitos acerca da prototipação; em seguida, na Seção 4 é apresentada a abordagem
proposta e ilustrada através de um estudo de caso, um sistema para biblioteca estudantil;
por fim, na Seção 5 são apresentadas as conclusões.

2. UML
A UML é uma linguagem não proprietária desenvolvida para especificar, construir,
visualizar e documentar software. É mantida pelo OMG (Object Management Group) e
recebeu contribuições e direito de autoria de várias empresas privadas, como a HP,
IBM, Microsoft, Oracle, ObjectTime, Platinum, Ptech, Rational, ICON Computing, i-
Logix, InteliCorp, Electronic Data Services, Reich, Softam, Sterling, Taskon A/S e
Unisys (BOOCH et al., 2000; RAMOS, 2006).
O objetivo da UML é ser uma linguagem de modelagem independente da
linguagem de programação, de ferramentas CASE e de processos de desenvolvimento.
Ela não é uma metodologia de desenvolvimento, ou seja, ela não define os passos para
o desenvolvimento de um projeto, mas fornece um meio de representação de sistemas
de informação que auxilia a documentação, compreensão do projeto e a comunicação
entre os desenvolvedores.
A documentação de um software utilizando a UML é feita através da
representação do sistema em diagramas, cada um dando uma visão e nível de
detalhamento específico e complementar aos outros. Cada visão deve ser intimamente
relacionada com as outras visões, de forma que os diagramas se apresentem coesos e
coerentes em relação aos demais (BOOCH et al., 2000).
A UML 2.0 define 13 diagramas, divididos em três categorias: seis diagramas
estruturais (diagrama de classes, diagrama de objetos, diagrama de componentes,
diagrama de instalação, diagrama de pacotes, diagrama de estrutura), três diagramas
comportamentais (diagrama de caso de uso, diagrama de estados, diagrama de
atividade) e quatro para diagramas de interações (diagrama de sequência, diagrama de
interatividade, diagrama de colaboração ou comunicação, diagrama de tempo) (OMG,
2011).
Neste trabalho são abordadas técnicas para auxiliar a concepção dos diagramas
de casos de uso, de classe e de sequência, que apresentam respectivamente visões do
comportamento externo, estrutural e interativo do sistema. Estes diagramas são os mais
usados nas fases iniciais da maioria dos processos de software.

3. Prototipação
A prototipação, no contexto de sistemas de informação, consiste na produção rápida de
sistemas simplificados (protótipos) com os quais podem ser realizadas experimentações
e verificações para avaliar e validar suas funcionalidades. Essa técnica é muito usada
para a elucidação e refinamento de requisitos, bem como para validação destes
(SOMMERVILLE, 2003).
A prototipação é útil quando não se tem muitas informações sobre os requisitos
de um sistema, seja pela dificuldade em obtê-los dos usuários ou pela própria
complexidade do sistema. Um erro grave que ocorre na prototipação é o aproveitamento
do protótipo para construir o sistema a ser entregue ao usuário. É importante observar
que este protótipo deverá servir apenas para validar e elucidar os requisitos
(PRESSMAN, 2006) (SOMMERVILLE, 2003).
A atividade de prototipação reduz os riscos de fracasso no processo de
desenvolvimento de software pois, equívocos entre usuários e desenvolvedores são mais
facilmente expostos nas fases iniciais do processo de desenvolvimento do sistema. Bem
como funcionalidades esquecidas e mal definidas podem ser identificadas e corrigidas.
Neste trabalho utilizamos a prototipação de interfaces que têm o objetivo de
ajudar no processo de comunicação entre o engenheiro de software e o usuário para
melhor definição dos requisitos. Com requisitos definidos, a elaboração do diagrama de
casos de uso é facilitado e daí os outros diagramas podem ser gerados.

4. Abordagem Proposta
A abordagem proposta será apresentada por meio de um exemplo, um sistema de
biblioteca, um sistema razoavelmente simples e bem conhecido. Será dada uma ênfase
na qualidade dos requisitos levantados visto que ela influencia diretamente na qualidade
final do produto de software.
O desenvolvimento dos diagramas UML e dos protótipos de interface foi
dividido em seis passos: 1º- Definição dos Requisitos do Sistema; 2º- Construção do
Diagrama de casos de Uso e dos Protótipos de Interface; 3 º- Construção dos Cenários;
4 º- Validação dos Casos de Uso Através dos Protótipos de Interface; 5 º- Construção
do Diagrama de Classes; e 6º- Construção dos Diagramas de Sequência, Figura 1.

Figura 1. Etapas do processo de desenvolvimento de software.

4.1. Passo 1 - Definição dos Requisitos do Sistema

Propõe-se para esta fase a representação dos requisitos do sistema de forma: a) gráfica –
através do diagrama de casos de uso; b) textual – através da descrição dos cenários; e c)
visual – através de protótipos de interface.
Inicialmente o engenheiro de requisitos deve buscar compreender o contexto
no qual o sistema proposto vai atuar. Para isso deve sistematizar a situação problema e,
posteriormente, fazer reuniões com o(s) representante(s) do cliente, com intuito de
levantar suas necessidades. Caso julgue necessário, questionários também podem ser
aplicados nessa fase.
Após a identificação do que o sistema deve fazer, ou seja, qual informação deve
ser processada, as funcionalidades a serem implementadas, as restrições existentes e os
critérios que determinam o sucesso e a aceitação do projeto, o engenheiro de software
deve construir uma tabela listando os principais requisitos funcionais e não funcionais
do sistema, como desempenho, segurança e robustez. Uma tabela simplificada de
requisitos do sistema de biblioteca está apresentada na Tabela 1.
Tabela 1. Requisitos do Sistema de Biblioteca
· Manter atualizado o cadastro de exemplares da biblioteca e seu status (emprestado ou
disponível).
· Manter atualizado o cadastro de usuários da biblioteca e seu status (liberado ou suspenso).
· Permitir que os usuários pesquisem exemplares disponíveis na biblioteca localmente ou
remotamente.
 · Controlar o empréstimo de obras.
· Permitir reservas via internet ou locais para os usuários cadastrados.
· Manter o controle das multas dos usuários.
· Gerar estatísticas de uso da biblioteca.
· Não permitir acesso a pessoas não autorizadas.
Dar-se então início ao processo de modelagem dos requisitos utilizando um
diagrama de casos de uso simplificado. Este processo inicia com a descoberta dos atores
do sistema e prossegue com a descoberta do(s) caso(s) de uso associados com estes
atores. Nesta etapa devem ser definidos somente os casos de uso principais para cada
ator e não devem ser usadas relações do tipo include, generalization e extends. O
objetivo desta fase é definir os atores que interagem com o sistema e as principais
funcionalidades que este deve prover. Considerando o nosso exemplo, na Figura 2 é
apresentado o diagrama de casos de uso nível 0 do sistema de uma biblioteca.

Figura 2. Diagrama de Casos de Uso Nível 0 do Sistema de Biblioteca.

4.2. Passo 2 - Construção do Diagrama de casos de Uso e dos Protótipos de

Interface
O diagrama de casos de uso desenvolvido visando o entendimento do contexto do
sistema deve ser expandido, originando um segundo diagrama de casos de uso mais
detalhado do que o primeiro. Neste diagrama, Figura 3, foram incluídos somente os
atores principais do sistema e as suas principais funcionalidades. Em fases seguintes do
desenvolvimento do sistema, este diagrama pode ser expandido através da inserção de
novos usuários, como o Administrador, e novas funcionalidades, como editar e excluir
cadastro de obras e usuários. É importante observar que este diagrama pode ser mais ou
menos detalhado de acordo com os requisitos que já são conhecidos. Em alguns casos,
pode-se partir do diagrama de casos de uso nível 0 para a construção do protótipo.
Os protótipos das interfaces devem ser construídos paralelamente aos diagramas
de casos de uso. Como a definição de interfaces é mais natural e intuitiva do que a
construção de casos de uso, a elaboração dos seus protótipos torna a construção dos
diagramas de caso de uso mais fácil, além de diminuir a probabilidade de se esquecer
algum caso de uso. Na Figura 4 é exibido o protótipo da tela Emprestar Obra, sistema
de biblioteca.
 Figura 3. Diagrama de Casos de Uso Nível 1 do Sistema de Biblioteca.

Figura 4. Protótipo da Tela Emprestar Obra.

4.3. Passo 3 - Construção dos Cenários

Após a definição dos casos de uso e seus respectivos protótipos de interfaces, devem ser
descritos os cenários primários e os secundários de cada um dos casos de uso. Na
Tabela 2 é exemplificada a descrição dos cenários do caso de uso Emprestar Obra. Os
fluxos alternativos não foram apresentados por questões didáticas.
Tabela 2. Cenários do Caso de Uso Emprestar Obra.
Caso de Uso: Emprestar Obra
Atores: Funcionário.
Pré-requisito: O Funcionário deve ter feito login no sistema.
Descrição: Efetua o empréstimo de uma obra para um Usuário.
Fluxo de Eventos Principal:
1. Verificação do Usuário [Caso de uso Verificar Usuário];
2. Se o usuário estiver cadastrado no sistema, sua senha estiver correta e não tiver nenhuma
pendência na biblioteca é exibida a mensagem: “Usuário sem restrições !”;
3. É solicitado o código da obra e exibido os botões “Verificar Obra” e “Pesquisar”;
4. O Funcionário digita o código da obra e clica em “Verificar Obra”;
5. Se a obra estiver cadastrada é exibido o nome, a localização, o tipo e o status da obra e
solicitada a senha do Funcionário e o botão “Emprestar”;
6. Se o status da obra estiver “disponível” o Funcionário digita sua senha e clica em Emprestar;
7. Se a senha do Funcionário estiver correta o sistema imprime o comprovante do Usuário;
8. Fim do caso de uso.

4.4. Passo 4 - Validação dos Casos de Uso Através dos Protótipos de Interface
Deve-se apresentar os protótipos das interfaces ao(s) usuário(s) explicando-lhe(s) a
sequência de operações realizadas e a sequência de telas exibidas durante a realização
de uma funcionalidade. Essas sequências devem estar coerentes com os cenários
desenvolvidos. Todos os cenários primários e secundários devem ser descritos
utilizando os protótipos e interface. Durante o processo, as dúvidas do usuário devem
ser esclarecidas e todos os comentários e sugestões pertinentes devem ser registrados.
As deficiências encontradas nessa iteração devem subsidiar a elaboração de novos
diagramas de casos de uso, interfaces e cenários que devem ser novamente validados
pelo usuário. Esta etapa encerra-se após a definição completa e detalhada dos casos de
uso, interfaces e cenários validados pelo usuário.
A utilização de protótipos de interface provê um processo mais objetivo de
validação dos requisitos funcionais com o usuário do que o uso direto do diagrama de
casos de uso. Apesar de natural para os engenheiros de requisitos experientes, o
diagrama de casos de uso não é facilmente compreendido pelo usuário, o protótipo de
interface provê uma representação mais real do sistema em desenvolvimento, próximo
da utilização cotidiana do sistema. A construção de protótipos de interfaces é mais
simples do que a construção de um protótipo funcional, podendo ser realizada por um
profissional sem conhecimento de nenhuma linguagem de programação. Outro
benefício é que o processo resulta na criação de alguns documentos (diagramas de caso
de uso e cenários), validados pelo usuário, que serão usados nas fases seguintes da
modelagem.

4.5. Passo 5 - Construção do Diagrama de Classes

A partir dos protótipos de interfaces e diagrama de casos de uso deve-se iniciar a
construção do diagrama de classes. Sugere-se que este diagrama seja construído sob
uma arquitetura de três camadas, a saber: camada de apresentação, camada de negócios
e camada de dados.
Inicialmente devem ser definidas as classes da camada de aplicação. Essas
classes correspondem às telas do sistema, devendo cada uma delas ser representada por
uma classe. Somente os nomes das classes devem ser definidos nessa camada.
A seguir deve-se definir as classes da camada de dados. Todos os objetos
persistentes no sistema devem ser representados por uma classe nesta camada. Uma
forma simples de identificar os dados persistentes é procurando nos protótipos telas de
cadastro, de geração de históricos e de auditorias que necessitam ser armazenados
persistentemente. O objetivo da camada de dados é o armazenamento de informações,
sendo necessário explicitar os atributos de cada destas classes. Os métodos destas
classes não precisam ser definidos. Frequentemente as classes desta camada se
relacionam entre si por meio de associações e generalizações. Recomenda-se também
explicitar a multiplicidade das relações. Esta camada do diagrama de classes pode ser
usada para a definição das tabelas para o banco de dados do sistema.
A seguir, deve-se definir as classes da camada de negócio. As classes dessa
camada são as responsáveis por controlar o funcionamento do sistema, também
chamadas de regras de negócio, devendo portanto implementar operações de aquisição e
envio de dados para as interfaces do sistema e inserção, atualização exclusão e consulta
de dados persistentes. Como o foco dessa camada são as operações realizadas sobre e
pelo sistema, somente os métodos das classes devem ser definidos.
Na Figura 5 é exibido o diagrama de classes do sistema de biblioteca, construído
de acordo com as técnicas descritas acima, onde foram representados somente o nome
das classes e seus relacionamentos.

Figura 5. Diagrama de Classes Simplificado do Sistema de Biblioteca.

Desenvolver o diagrama de classes em camadas resulta, na maioria dos casos,
em um diagrama mais organizado e compreensível. Além disso, a divisão em camadas
torna o processo de criação do diagrama de classes mais fácil, pois se define
isoladamente as classes de cada camada, com características bem definidas. A divisão
do diagrama de classes em camadas também torna mais fácil a construção do banco de
dados, o que pode ser feito a partir das classes da camada de dados e seus respectivos
relacionamentos.
4.6. Passo 6 - Construção dos Diagramas de Sequência
Após a construção do diagrama de classes deve ser iniciado o desenvolvimento dos
diagramas de sequência. Estes diagramas devem ser gerados a partir das informações
dos cenários e do diagrama de classes. Para cada cenário deve ser desenvolvido um
diagrama de sequência.
Eles devem também apresentar arquitetura em camadas da mesma forma que o
diagrama de classes. Para isso devem ser representados mais a esquerda nos diagramas
de sequência o(s) ator(es) que participam de processo, seguido de um ou mais objetos
da camada de apresentação com o qual o(s) ator(es) interagem, em seguida pelos
objetos da camada de negócios responsáveis por controlar esse processo e,
opcionalmente, de um ou mais objetos da camada de dados usados para realizar a
funcionalidade em questão.
A sequência das mensagens deve seguir a ordem descrita nos cenários, e as
mensagens enviadas para um objeto de controle deve corresponder a um método
definido no diagrama de classes para esse objeto. Desta forma, os diagramas de
sequência são construídos a partir dos cenários e diagrama de classes. Na Figura 6 é
exibido um diagrama de sequência do cenário principal do caso de uso Emprestar Obra,
apresentado na Tabela.

Figura 6. Diagrama de sequência do cenário principal do caso de uso Emprestar

Obra.

5. Conclusões
A abordagem apresentada neste artigo pretende tornar o processo de modelagem de
requisitos mais fácil e eficiente, provendo através do uso de protótipos de interface uma
forma mais simples de interagir com os usuários e, assim, validar os requisitos
modelados no diagrama de casos de uso. Também apresenta uma forma de construir os
diagramas de classe e de sequência de forma mais objetiva, garantindo a coerência entre
as representações do sistema. Essa coerência é garantida pelo fato de um diagrama ser
gerado a partir de informações de outro, previamente construído.
 Esta abordagem não é uma regra que precisa ser seguida rigorosamente.
Consiste em várias técnicas que podem ser aplicadas em conjunto, ou isoladamente, ou
até mesmo adaptadas de acordo com os conhecimentos e necessidades de cada
indivíduo. Ela abordagem pode ser usada junto com a maioria dos processos de
desenvolvimento de software modernos.
Pretende-se avaliar esta abordagem de forma qualitativa usando como grupo de
teste composto por alunos de graduação do curso de Engenharia da Computação da
UNIVASF, submetendo-os a atividades de desenvolvimento de diagramas da UML
seguindo a abordagem proposta e em seguida aplicando questionários visando avaliar a
efetiva eficácia das técnicas propostas.

Referências
ANDRETO, D. E. et al. Desenvolvendo de Software: Uso da Prototipação na fase de
Concepção do Modelo de Processo de Software RUP. Iniciação Científica
CESUMAR. v. 08, n.01, p.27-33 Maringá - PR, Brasil. 2006. Disponível em:
<http://www.cesumar.br/pesquisa/periodicos/index.php/iccesumar/article/viewFile/
133/71>. Acesso em: 5 Nov 2011.
BECK, K. Embracing change with extreme programming. IEEE Computer, n.10,
v.32, p.70-78.
BOOCH, G., et. al. UML, guia do usuário. Rio de Janeiro: Campus, 2000.
D’SOUZA, D. F. et al. Objects, Components and Frameworks with UML – The
Catalysis Approach. USA: Addison Wesley Publishing Company, 1999.
DEBONI, J. E. Z.; CASTRO, J. F. B. Breve Introdução aos Diagramas da UML.
Voxxel Consultoria de sistemas 2009. Disponível em:
<http://www.marcelocampos
.com.br/academico/estagio1/download/aula003ex2.pdf>. Acesso em: 5 Nov 2011.
OMG. Introduction to OMG's Unified Modeling Language™ (UML®). 2011.
Disponível em: <http://www.omg.org/gettingstarted/what_is_uml.htm>. Acesso em:
27 Mar 2011.
KRUCHTEN, Philippe. Introdução ao RUP - Rational Unified Proccess. Rio de
Janeiro: Ciência Moderna, 2003.
PRESSMAN R. S. Engenharia de Software. 6a edição - McGraw-Hill Interamericana
do Brasil, 2006.
RAMOS, R. A. Treinamento Prático em UML. São Paulo: Digerati, 2006. v. 1. 144
p.
SANTANDER, V. F. A.; CASTRO, J. F. B. Desenvolvendo Use Cases a Partir da
Modelagem Organizacional. III Workshop de Engenharia de Requisitos, Rio de
Janeiro - RJ, Brasil. 2000. Disponível em:
<http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER00/santander.pdf>.
Acesso em: 5 Nov 2011.
SOMMERVILLE, I. Engenharia de software. 6. ed. São Paulo: Addison Wesley,
2003.