Unidade Curricular 01

1
Prof. Sérgio Luiz Tonsig
 Atualmente qualquer atividade humana tem a participação direta ou indireta de software. Em
geral ele é percebido através de sistemas de informação, pois é a um dos elementos principais para
seu funcionamento.

Entretanto, a construção de sistemas de informação segue etapas, que podem ter pequenas
diferenças, dependendo do ambiente para o qual o sistema está sendo criado. Por exemplo, fazer
um sistema que envolvem dispositivos móveis tem certos requisitos que não seriam necessários, caso
o sistema fosse apenas para Web.
Dado a complexidade atual das estruturas, inter-relações, aspectos de negócios, os
mecanismos de construção de um sistema envolvem uma estratégia importante: a realização de
modelagens.
A criação de um produto baseado em software (sistemas de informação ou automação), a
exemplo de outros tipos de produtos, precisam de uma avaliação prévia das partes que irão compô-
lo, para identificação de eventuais inconsistências ou problemas, antes de sua construção efetiva.
Um modelo ajuda a verificar aspectos de uma realidade, de uma forma mais rápida e sem alto
custo; orientando assim a definição final do projeto do software.
O objetivo dessa unidade curricular é uma introdução ao processo modelagem de sistemas,
promovendo um entendimento preciso sobre essa abordagem, apresentando as perspectivas que a
modelagem pode ser aplicada e, como isso poderá trazer benefícios a construção do projeto de
sistemas.

2
Prof. Sérgio Luiz Tonsig
Sumário
1. Modelagem de Sistemas .................................................................................................................... 4
1.1. Conceito de Modelagem ......................................................................................................... 4
1.2. Modelagem de Processos. .......................................................................................................... 6
1.2.1. Importância da modelagem de Processos. .......................................................................... 6
1.2.2. Abordagens de Modelagens. ................................................................................................ 7
1.2.3. Informações sobre o Processo. ............................................................................................ 7
1.3. Diagramação de Processos.......................................................................................................... 7
1.3.1. Notações atualmente existentes. ......................................................................................... 8
1.3.2. Notações Gráficas Utilizadas ................................................................................................ 9
2. Informações e Processos nas Empresas .......................................................................................... 12
2.1. Dados, informação e conhecimento são a mesma coisa? ........................................................ 12
2.2. O que é Informação? ................................................................................................................. 15
2.3. O que é conhecimento? ............................................................................................................ 15
2.4. O que é qualidade da informação? ........................................................................................... 17
2.5. Sistemas de Informação ............................................................................................................ 17
2.6. Desenvolvimento Modelagens para Diversas Perspectivas de Sistemas. ................................ 19
3. Modelagem com UML...................................................................................................................... 20
3.1. Modelagem e Requisitos ........................................................................................................... 21
3.2. Perspectivas na UML. ................................................................................................................ 21
3.2.1. Modelos de descoberta de Requisitos ............................................................................... 24
3.2.2. Requisitos funcionais e não funcionais. ............................................................................. 24
4. Criando Diagramas com UML .......................................................................................................... 26
4.1. Visão Externa – Casos de Uso.................................................................................................... 27
Referências Bibliográficas .................................................................................................................... 29

3
Prof. Sérgio Luiz Tonsig
1. Modelagem de Sistemas

1.1. Conceito de Modelagem

Essa aula via nos levar a refletir sobre todos os aspectos que envolvem responder à questão
abaixo:
- O que é Modelagem?
A palavra modelagem, segundo dicionário Michaelis é “Ato ou resultado de modelar; moldação,
moldagem, modelação.”.

O conceito aplicado ao software, segundo a Wikipédia é: “Uma atividade de construir modelos

que expliquem as características ou o comportamento de um software.”.

Muitos analistas e gestores de negócio têm apostado na modelagem de processos como prática
para compreender, comunicar e otimizar os processos.

Figura 01 – Modelagem – sobreposição de perspectivas

As perspectivas sobre aquilo que se modela podem explicar comportamentos, ideias,

soluções pensadas sobre algo.

4
Prof. Sérgio Luiz Tonsig
 As perspectivas também podem evoluir, para etapas subsequentes do produto, ou
transitarem de um estado para outro, conforme mostra a figura 02.

Figura 02 – Modelagem – etapas subsequentes na construção do produto.

- Quais são as semelhanças existentes nos entre as imagens da figura 01 e a 02 com a

modelagem de sistemas de informação?

Sistemas de informação possuem diferentes perspectivas para avaliação. São partes que
precisam ser examinadas separadamente e, depois, em conjunto. Algumas possíveis perspectivas
são:

 processos
 dados
 interface
 comunicação
 ambientes
 integrações
 dinâmica
Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de um
sistema em que cada modelo apresenta uma visão ou perspectiva diferente do sistema. Pode-se
desenvolver modelos do sistema existente ou do sistema que se pretende desenvolver.

5
Prof. Sérgio Luiz Tonsig
1.2. Modelagem de Processos.

Modelagem de Processos de Negócio ou Business Process Modeling é a representação dos

processos de negócio de uma organização, com o objetivo de documentar, entender e analisar os
processos, permitindo a melhoria contínua, transformação, integração ou automação do todo ou
parte.
Através da representação das atividades, usualmente em diagramas de processos é possível
obter uma visão lógica das atividades e entender, de forma simples e intuitiva, como o trabalho é (ou
deve ser) feito em uma empresa.

1.2.1. Importância da modelagem de Processos.

Os principais benefícios da modelagem de processos, podem ser vistas a seguir.

a) Promove uma visão compartilhada do processo.

Ter um diagrama de processo facilita muito na hora de documentar e disseminar o
processo, alinhando o entendimento entre todos os envolvidos. A representação gráfica
é uma forma de exteriorizar o conhecimento que estaria na cabeça de uma única pessoa
e passa a ser transmitido para todas as partes envolvidas.

b) Melhora a comunicação entre as pessoas.

A comunicação é melhorada porque ela é sistematizada a partir de princípios da
representação gráfica, evitando dualidade de interpretações, esquecimentos, mal
entendimento, etc.

c) Evita atrasos e desperdícios diversos.

A modelagem de processos é utilizada auxiliando diretamente na análise do processo, pois
permite entendê-lo de forma clara. A diagramação do processo atual possibilita enxergar
gargalos e outros problemas que antes eram difíceis de notar. Assim, é possível tomar as
medidas necessárias para corrigir esses problemas e, posteriormente, documentar o
processo transformado.

d) Auxilia no treinamento e desenvolvimento de colaboradores.

Ao contratar um novo colaborador ou treinar um profissional que já trabalha na empresa
a modelagem de processo é extremamente útil. Pode ser um guia para que a pessoa tenha
uma visão geral do trabalho.

6
Prof. Sérgio Luiz Tonsig
 e) Facilita a automação de processos.
Dependendo da notação utilizada, a diagramação resultante da modelagem de processos
pode ser convertida em uma linguagem compreensível por ferramentas de automação de
processos, chamadas de BPMS. Estas ferramentas utilizam o diagrama mapeado em
BPMN para criar um workflow automatizado, facilitando o cotidiano dos colaboradores e
aumentando o controle sobre o processo.

1.2.2. Abordagens de Modelagens.

Existem três tipos de abordagens para modelagem de processos.

 De cima para baixo (top-down): primeiro é construída uma visão macro do processo para
depois detalhar o restante do trabalho.
 Do meio para fora (middle-out): concentra-se no núcleo do problema do processo para
depois ir em direção às suas extremidades.
 De baixo para cima (bottom-up): primeiro são entendidos os detalhes do trabalho para depois
construir uma visão macro do processo.

1.2.3. Informações sobre o Processo.

Para criar um modelo de um processo é preciso primeiro compreendê-lo, fazendo um

detalhado levantamento de informações sobre as atividades. Como devem ser executadas e em que
ordem, quem faz o quê e, de que forma. Porque fazem de um jeito e, não de outro.

Levar em consideração todas as regras internas e políticas que envolvem o processo, além
dos aspectos de legislação. A organização e integridade dos processos, em grande parte atendem
esses quesitos.

Algumas estratégias devem ser utilizadas para o levantamento dessas informações, tais como:
entrevistas individuais com os colaboradores, entrevista com um grupo de colaboradores,
observação da rotina das atividades executadas com respectivos questionamentos, verificação de
documentos relacionados ao processo, etc.

1.3. Diagramação de Processos

Após ter realizado o levantamento de informações sobre o processo e, ter entendido todo
fluxo de trabalho, é necessários definir uma ferramenta para documentar a representação do
conteúdo. Há várias formas para isso. O ideal é sempre escolher um padrão de mercado, a fim de
que outras pessoas consigam entender o processo. As ferramentas obedecem notações gráficas.

7
Prof. Sérgio Luiz Tonsig
Uma notação é um padrão, uma linguagem de representação de processos. Pode ser descrita
também como um conjunto de símbolos e regras para representar as informações.

1.3.1. Notações atualmente existentes.

Existem diversas notações no mercado e cada uma delas possui uma finalidade. Confira uma
lista com as principais notações e seus usos indicados:

 BPMN (Business Process Model and Notation): útil para apresentar um modelo para públicos-
alvo diferentes.
 Fluxograma: simples e amplamente conhecido, facilita o entendimento rápido do fluxo de um
processo.
 EPC (Event-driven Process Chain): útil para modelar conjuntos complexos de processos.
 UML (Unified Modeling Language): modela características estruturais e dinâmicas de sistemas
de informação.
 IDEF (Integrated Definition Language): destaca entradas, saídas, mecanismos, controles de
processo e relação dos níveis de detalhe do processo superior e inferior.
 Value Stream Mapping: ajuda a mostrar a eficiência de processos por meio do mapeamento
do uso de recursos e elementos de tempo.

Figura 03 – Diagramação de Processo com Ferramenta BizAgi.

A notação BPMN possui um conjunto de símbolos gráficos de fácil entendimento e, reunidos

através de regras simples, permitem um perfeito entendimento de processos.

8
Prof. Sérgio Luiz Tonsig
 Figura 04 – Simplicidade na notação BPMN.

1.3.2. Notações Gráficas Utilizadas

A seguir as principais notações gráficas utilizadas no BPMN, através da ferramenta BizAgi.

Figura 05 – Ilustrações de algumas notações

9
Prof. Sérgio Luiz Tonsig
 Figura 06 – Notação Gráfica para Atividades

Um agrupamento de atividades pode formar um processo ou um subprocesso, conforme a

imagem 07 apresenta.

Figura 07 – Notação Gráfica para Processos e Subprocessos

10
Prof. Sérgio Luiz Tonsig
 Toda especificação do fluxo de atividades que formam determinado processo se dá em “raias
de responsabilidade”, onde se indica quem executa tais ações.

Figura 08 – Notação Gráfica para Raias de Responsabilidade.

Veja a seguir um exemplo de um processo de depósito em um caixa eletrônico, utilizando

envelopes para armazenar dinheiro ou cheque.

Figura 09 – Exemplo da utilização das notações gráficas.

11
Prof. Sérgio Luiz Tonsig
2. Informações e Processos nas Empresas

Qualquer empresa, independentemente de sua finalidade, tem que se preocupar com três
fatores Pessoas, Produtos e Processos.
Relativo aos processos, essencialmente temos a informação como um dos principais
elementos na tomada de decisão. Ela reduz as incertezas de uma ação, contribuindo com elementos
para análise.
A tomada de decisão pode ser considerada um processo que envolve a seleção de um
caminho, dentre vários possíveis, a ser trilhado e a definição de um curso de ações, para se chegar a
uma solução de um dado problema que a empresa possue; ou uma estratégia que ela deseja
estabelecer.

De onde vem a informação? Hoje, invariavelmente, em sua grande maioria, é gerada pelos
sistemas de informação. A informação não é obtida apenas por conta de que a empresa virá a utilizá-
la para alguma decisão, mas é necessário atentar-se ao fato de que muitas informações devem ser
mantidas por exigências de legislação, o que significa custos financeiros e operacionais paras as
empresas. Assim, qualquer sistema que vier a ser planejado, deve levar em consideração essa
obrigatoriedade dentro da área que irá ser utilizado.

Mesmo em empresas de menor porte, hoje existe um grande volume de informações a serem
tratadas pelos sistemas. Essas informações são provenientes de diversas áreas diretas ou
indiretamente ligadas ao negócio da empresa.

É muito comum as pessoas não estabelecerem um diferencial claro entre alguns termos nas
empresas; especialmente no que ser refere a: dado, informação e conhecimento. A generalização de
um desses termos é mais usual. Entretanto, para os profissionais da Tecnologia da Informação, é
necessário ter uma definição clara sobre esses aspectos, uma vez que um sistema de informação,
pode gerar conhecimento ou informações, a partir de dados.

Com base no conhecimento ou informações obtidas nos sistemas, as organizações tomam

decisões na condução de seus negócios; portanto, é crucial que se deva também conhecer como,
genericamente, estas organizações estão estruturadas para tomada de decisão, a fim de que se possa
melhor preparar os sistemas de informação, inclusive para serem aplicados como auxiliadores nas
tomadas de decisão.

2.1. Dados, informação e conhecimento são a mesma coisa?

Podemos considerar o dado uma unidade fundamental dos sistemas de informação. O dado
representa uma característica ou propriedade de algo, ou de alguém. Sozinho, o dado não tem
nenhum sentido.
Observe esse conteúdo: 11/01/2015.

12
Prof. Sérgio Luiz Tonsig
 O que significa 11/01/2015? Todos nós conseguimos deduzir, pelo seu formato, que se trata
de uma data. Podemos ainda deduzir que se encontra no século XXI. O mês é janeiro e o dia 11. Por
uma coincidência surpreendente, pode ser que para você ela tenha algum significado específico,
como a data do seu nascimento; mas isso não está explicito ali. Podemos ficar fazendo exercícios
fúteis de imaginação: seria a data de lançamento de algum modelo de avião, descoberta de algo,
término de um campeonato, falecimento de alguma celebridade? Ou seja, esse conteúdo sozinho
não tem significado.

Para melhorar a situação anterior, podemos criar um conjunto de dois elementos. Um

atributo e o seu conteúdo.
Vamos criar um atributo cujo nome será data de nascimento e, em seguida associar e ele um
conteúdo.

data_de_nacimento = 11/01/2015.

O que obtemos na linha acima, é o que chamamos de dado. Dado é a união de um atributo e
seu respectivo conteúdo. Veja outros exemplos de atributo (apenas): nome, cpf, email, função,
valor_total. Perceba que ainda não associamos conteúdo a esses atributos.
Olha agora o exemplo abaixo:

nome = Pedro

Você percebe que um dado sozinho, fora de um contexto, não expressa algo que traga qualquer
certeza, ou elimine dúvidas de qualquer natureza. Pedro é o nome de quem? Quem é essa pessoa (?)
que se chama Pedro? Seria pouco improvável que se desse esse nome a um cachorro; muito embora
não seja impossível. Entretanto, poderia ser o nome de um robô. Não temos como afirmar que trata-se
de uma pessoa.

O conceito de dados pode ser expresso conforme mostra a figura 10.

Figura 10 – Estrutura do Elemento de Dado

13
Prof. Sérgio Luiz Tonsig
 Os dados podem ser considerados características ou propriedades básicas de algo ou alguém
(pessoas, documentos, objetos, situações e concatenações destas coisas), cujo conteúdo deve ser
unívoco. O dado não deve comportar mais de um conteúdo para o seu atributo (figura 11).

Figura 11 – Conteúdo por Dado

Portanto, de acordo com o conceito mencionado anteriormente, seria equivocado criar um
atributo “telefone” e colocar como conteúdo dele, vários telefones. O ideal, nesse caso, seria criar
atributos diferentes para cada conteúdo: telefone_residencial, celular1, celular2, telefone_principal,
etc.
Para se possa dar sentido aos dados, devemos agrupá-los em um contexto. Então, pode-se
pegar os elementos de dados que sejam propriedades de uma mesma entidade (pessoa, objeto,
documento, situação) e, agrupá-los de maneira a formar o que é chamado de registro1 da entidade,
ou ainda, tupla2 da entidade.

DADO
ATRIBUTO VALOR OBSERVACÕES
Nome Virgulino F. da Silva Nome da Pessoa
Data Nascimento 01/03/1898 Data em que a pessoa nasceu no formato
dd/mm/aaaa
Sexo Masculino Masculino/Feminino
Naturalidade Serra Talhada Local onde a pessoa nasceu
Altura 1,70m Tamanho da pessoa em metros
Celular 9897-9899 Número do telefone celular da pessoa

Tabela 1 – Exemplo de dados de uma pessoa

A tabela 1 especifica um conjunto de atributos sobre uma pessoa. Esta tabela poderia ser
reconstruída conforme mostra a tabela 2, onde cada linha faz referência a uma pessoa, mostrando o

1
Nomenclatura utilizada para armazenamento de dados em arquivos. O conjunto de registros referente a uma mesma
entidade, forma um arquivo daquela entidade.

2
Nomenclatura empregada para armazenamento de dados utilizando-se banco de dados relacionais. A função é similar
aos do registro. Várias tuplas de uma mesma entidade constituem a tabela daquela entidade.

14
Prof. Sérgio Luiz Tonsig
conteúdo de seus atributos. O conjunto de linhas (registros ou tuplas) formam um arquivo ou tabela
sobre pessoas.

Rg Nome Data Nascimento Sexo Naturalidade Altura Celular

14.285.258 José da Silva 21/06/2000 Masculino Lagoas 1,60 9898-7654

12.765.767 Joaquim Manoel 25/12/1959 Masculino Sussuro 1,70 9897-9899

13.767.543 Emanuela Gilter 23/01/1974 Feminino Coaltum 1,65 9192-9394

14.768.769 José da Silva 25/12/1959 Masculino Sussuro 1,60

12.987.879 Carmem Barbosa 12/04/1963 Feminino Lagoas 1,75

Tabela 2 – Registro de Pessoas

2.2. O que é Informação?

As tabelas mostradas anteriormente com registros de pessoas, podem ser convertidas em informação
através de algum mecanismo de estruturação ou de decodificação; como por exemplo, um relatório ou a
apresentação dos dados em uma tela de consulta.

Os dados reunidos passam a apresentar um significado, de tal maneira que podem ser interpretado
pelas pessoas, produz-se informação. A informação, sempre tem um contexto. Ela reduz a incerteza sobre um
determinado estado de coisas, mostra um sentido consistente sobre algo (TONSIG, 2008).

Ainda considerando a tabela de pessoas, de acordo com os atributos lá existentes, é possível

criar-se um mecanismo de estruturação (vamos supor um relatório) que pudesse nos informar, por
exemplo, quem são as pessoas aniversariantes desse mês e, em que dia fazem aniversário e, mais do
que isso, poderemos apresentar a informação em ordem crescente de dia (mas, se quem vai usar,
preferir em ordem alfabética, também é possível). E ainda, se houve alguém muito exigente e solicitar
que exista uma coluna no relatório que mostre a idade da pessoa, o relatório conseguirá fazer isso
também.

2.3. O que é conhecimento?

O conhecimento diz respeito a capacidade de resolver problemas, inovar e aprender baseado

em experiências prévias. Envolve a percepção sistematizada do que existe, o aprendizado do passado
e de experiências semelhantes, a compreensão de funcionamento e aplicação de sistemas associados
aos nossos objetivos e, finalmente, a criatividade proativa.

15
Prof. Sérgio Luiz Tonsig
 De acordo com o dicionário Aurélio, “Ato ou efeito de conhecer”, “Informação ou noção
adquiridas pelo estudo ou pela experiência”, “Prática da Vida; experiência”, “Discernimento, critério,
apreciação” ou “Consciência de si mesmo; acordo” (Ferreira, 1993).

Portanto, o conhecimento compreende a informação, mas envolve também a experiência e

depende do enfoque de quem está lidando com determinada informação.
Se retomarmos a tabela de pessoas vista anteriormente, é possível criar uma consulta ou
relatório que nos faça conhecer quem é a pessoa mais velha lá existente. Observe que isso é uma
dedução ou constatação, a partir das informações históricas lá existentes.

A história clássica que se conta para mostrar essa mineração do conhecimento, sobre uma
grande base de dados (big data ou data warehouse), é a de que, a partir do registro de vendas de
uma loja de conveniência 24 horas, foi constatado que a compra de fraudas (de neném) após as 21h
era realizada por pessoas do sexo masculino.
Veja, isso é um conhecimento. Não estava explicito nas informações geradas pelos dados.
Assim como em nossa tabela de pessoas, não está explicito quem é a mais velha. E, veja que
interessante: como não temos na tabela de pessoa a data de óbito, não temos como dizer, se dentre
aquelas cidades existe alguma em que as pessoas tenham maior longevidade.
Alguém, então, nesse ponto, pode estar pensando: para que me interessa saber isso? Se
existem pessoas de certa cidade vivem mais as que de outra? Ou que na loja de conveniência, após
as 21h são pessoas do sexo masculino que vão comprar fraldas?
No caso das lojas de conveniência, foi esse conhecimento obtido através dos sitemas de
informação que apoiou a decisão dos gestores em organizar suas gôndulas com a cerveja ao lado das
fraldas, aumentando a venda das mesmas após as 21h.

Figura 12 – Cerveja ao lado de fraldas na gôndola

16
Prof. Sérgio Luiz Tonsig
2.4. O que é qualidade da informação?

Qualidade é o grau de utilidade esperado ou adquirido de qualquer coisa, verificável através

da forma e dos elementos constitutivos do mesmo e pelo resultado do seu uso. A palavra "qualidade"
tem um conceito subjetivo que está relacionada com as percepções, necessidades e resultados em
cada indivíduo ou organização.
A qualidade da informação pressupõe a qualidade do dado, do sistema de informação e do ambiente
computacional. Todos os elementos participantes de um contexto de TI (Tecnologia da Informação) são peças
mutuamente dependentes, de onde a informação se origina. A qualidade deve estar no contexto de todos os
elos de onde se deseja obtê-la.

Um sistema de informação de qualidade pressupõe um sistema que cumpre seus objetivos, é

gerenciável, é passível de manutenção e de aprendizado por uma pessoa que não tenha feito parte
do grupo original que o projetou.
Ainda que seja um conceito subjetivo, é importante estabelecer os parâmetros de avaliação
para não gerar conflitos ou controvérsias sobre a utilidade de um sistema.
Sob a ótica de uma pessoa da tecnologia, um gráfico em pizza talvez possa ser algo que ele
julgue fazer parte do conjunto de qualidade do produto e, talvez sob a ótica do usuário, isso possa
ser irrelevante, já que gostaria de visualizar aquela mesma informação sob a ótica de relatório. É
portanto extremamente necessário o alinhamento dos sistemas com o planejamento estratégico da
empresa; tendo-se um cuidado especial com a interface (formas que as informações serão
apresentadas).

2.5. Sistemas de Informação

Os sistemas de informação são mecanismos que permitem a extração, processamento,

distribuição ou comunicação da informação a partir de um conjunto de dados.

Os sistemas de informação devem estar alinhados com as expectativas de seus usuários, no

que se refere a qualidade da informação, existência da informação necessária, facilidade de uso do
sistema, etc. O sistema de informação de uma empresa (figura 13) pode ser um diferencial
competitivo no mercado, se ele contribuir adequadamente para a gestão empresarial.

17
Prof. Sérgio Luiz Tonsig
 Figura 13 – Sistema de Informação

Os analistas de sistemas ou engenheiros de software, ao planejarem o desenvolvimento de

um novo sistema de informação, além do domínio do problema, tem que preocupar-se com as três
dimensões de sistemas de informação: organização, pessoas e tecnologia (figura 14).

Figura 14 – Dimensões de um Sistema de Informação

As três dimensões que envolvem o um sistema de informação, exigem atenção do analista ao

planejar um novo sistema e, trazem desafios:

 Disponibilidade das informações

 Tolerância a falhas
 Privacidade, Interceptação, Comunicação (Lei Geral de Proteção de Dados)
 Tempo de execução
 Espaço consumido (Big Data)
 Visualização dos dados
 Integrações (sistemas legados e ambientes heterogêneos)

18
Prof. Sérgio Luiz Tonsig
2.6. Desenvolvimento Modelagens para Diversas Perspectivas de
Sistemas.

Modelar um sistema é o processo de desenvolvimento de modelos abstratos que

determinarão o comportamento e recursos do sistema. A modelagem depende dos requisitos
levantados. Grande parte do sistema modelado, não tem forma visual (exceto telas e relatórios).

Figura 15 – Modelagens

O processo para desenvolvimento de um sistema começa quando alguém requisita um

software para resolver determinado problema ou necessidade. Pode ser que uma pessoa teve uma
ideia sobre um produto novo, que ainda não existe e, gostaria de estar desenvolvendo; como por
exemplo, um aplicativo que será um assistente pessoal para viagens de turismo espacial.
Na modelagem pode haver mais de um modelo para o mesmo sistema, cada qual
representando uma perspectiva diferente do mesmo sistema.

Figura 16 – Perspectivas

19
Prof. Sérgio Luiz Tonsig
3. Modelagem com UML

Em engenharia de software, a criação de sistemas passa antes pelo entendimento de qual é

o problema a ser resolvido, em certo “domínio de problema”; isto é, em certa área empresaria, como
por exemplo, informatizar um supermercado. Isso pode ser muito complexo. Para fracionar tal
complexidade e, entende-la por partes, pode-se utilizar a construção de modelos que exigem uma
linguagem de modelagem que inclua elementos visuais para expressar conceitos e uma notação
simples, mas poderosa para esses elementos.
Assim, durante vários anos, muitas propostas de pesquisadores foram apresentadas para a
modelagem de perspectivas de sistemas, como por exemplo, na década de 70, Peter Pin-Shan Chen
introduziu a modelagem de dados (utilizada até hoje).

Os recursos de modelagem sempre tentam acompanhar as estratégias tecnológicas em uso.

Com o advento da programação orientada a objetos, que começou a se popularizar no mundo na
década de 80, algumas iniciativas na modelagem de sistemas foram feitas para criar recursos
apropriados dentro da abordagem orientada a objetos. O problema é que essas propostas se
proliferaram de tal maneira que, em meados de 1994, passavam de cinquenta! Esse período ficou
conhecido como “guerra dos métodos”.
Os usuários não conseguiam decidir-se por uma forma de modelar e os fabricantes de
ferramentas de modelagem sentiam-se relutantes em entrar no mercado com tantas alternativas.
Assim, todos aguardavam uma solução com baixo custo não só de desenvolvimento das ferramentas,
mas também de treinamento, integração e padronização dos modelos. Foi nesse cenário que surgiu
a UML.
A primeira versão da UML foi publicada em outubro de 1994, quando Booch e Rumbaugh,
trabalhando na Rational Software Corporation, resolveram unificar seus métodos Booch e OMT que,
na época, eram aceitos mundialmente.
Um primeiro rascunho, a versão 0.8 do então denominado Método Unificado, foi lançado em
Outubro de 1995, quando Jacobson trouxe seu método OOSE, agregando-o aos outros dois. Esse
esforço resultou no lançamento das UML 0.9 e 0.91, respectivamente, em Junho e Outubro de 1996.
Posteriormente, o mercado de TI com suas empresas e outros pesquisadores contribuíram com suas
ideias, resultando na UML 1.1 em 1997.

Desde então, a responsabilidade pela evolução da UML ficou a cargo do OMG (Grupo de
Gerenciamento de Objeto), seu órgão aprovador.

Figura 17 – Logomarca UML

20
Prof. Sérgio Luiz Tonsig
3.1. Modelagem e Requisitos

A modelagem de um sistema, na maioria das vezes, envolve atividades e áreas

multidisciplinares, onde estão envolvidas pessoas com diferentes formações, diferentes pontos de
vista e diferentes interesses. O profissional que irá desenvolver as atividades da análise, deve estar
preparado para conviver nesse contexto.

Quando se fala em uma empresa pequena ou até média, de desenvolvimento de software,

normalmente não existe o “cargo de analista” ou de “engenheiro de software”. A empresa possui
apenas o que chama de “desenvolvedores”. O desenvolvedor, no caso, é uma pessoa que,
primeiramente terá que realizar as atividades da modelagem.
A modelagem se inicia com o entendimento sobre o que deve ser resolvido ou criado e, na
medida em que ela avança, ajuda a descobrir requisitos de software.

Figura 18 – Qualidades desejadas em um analista de sistemas.

3.2. Perspectivas na UML.

Na UML, os sistemas são constituídos por modelos que representam diferentes pontos de
vista, cada um descrevendo um aspecto particular da mesma solução. Esses pontos de vista são
denominados visões. Cada uma dessas visões utiliza uma notação e um conjunto de elementos
apropriados para sua compreensão. Vamos observar a seguir alguns comentários, que criam um
contexto para entendermos o significado de requisito de software.

21
Prof. Sérgio Luiz Tonsig
 A UML representa o sistema em cinco visões:

Figura 19 – Visões na UML.

As cinco visões da UML podem ser vistas como abstrações dos modelos. Cada visão dá
importância a determinado aspecto do sistema, deixando os demais de lado. Elas permitem
simplificar a modelagem e o desenho do sistema para melhor gerenciamento e manutenção dos
modelos, assegurando, assim, maior qualidade ao produto final.

a) Visão Casos de Uso.

Apresenta sob a ótica dos usuários do sistema, quais recursos deverão ser criados para que a
solução venha atender adequadamente as expectativas. Em geral os casos de uso são um elo entre
os atores externos e a parte interna do sistema (o software propriamente dito) e, isso suscita que,
entre eles, deva existe uma interface (em geral, tela).

b) Visão Lógica dos recursos.

Visão lógica, também conhecida como estática, é um ponto de vista arquitetônico que
permite estruturar e organizar o desenho do sistema de forma lógica. Ela especifica classes,

22
Prof. Sérgio Luiz Tonsig
subsistemas e pacotes lógicos do sistema. Apesar de ainda contar com a participação do cliente,
eventualmente pelo emprego de diagramas de objetos, essa visão traduz o ponto de vista dos
analistas, projetistas, desenvolvedores do sistema e quaisquer outros interessados.

A preocupação da visão lógica, ou estática, é descrever a funcionalidade proporcionada pelo

sistema para atender os requisitos de usuário constantes na visão de caso de uso. Para isso é
necessário estruturar e organizar o desenho de forma lógica, especificando as classes, subsistemas e
pacotes lógicos do sistema e as colaborações dinâmicas entre os objetos.

O diagrama de classes representa a estrutura estática do modelo, um resumo do modelo de

desenho, que servirá de base para a arquitetura do sistema, garantindo toda a funcionalidade
esperada pelo usuário.

A identificação de objetos constitui-se um desafio para quem for realizar a atividade. Ela deve
ser feita baseando-se em atributos e métodos que sejam necessários ao sistema a ser desenvolvido.

c) Visão do Processo.

A visão do processo permite entender a organização dos processos do sistema. Ela é

desenvolvida a partir das visões anteriores e permite capturar os aspectos estáticos e dinâmicos em
diagramas de interação, de atividade e de estado. Ela é desenvolvida na perspectiva do analista e do
desenvolvedor, mas também conta com a colaboração do usuário para validação, principalmente,
pelos diagramas de sequência.

d) Visão da Implementação

A visão de implementação captura as decisões de arquitetura para implementação do

sistema, especificando os subsistemas e suas dependências e seus componentes organizados em
camadas e hierarquias. Em um projeto, ela permite definir e distribuir os trabalhos de
implementação, calcular a quantidade de código a ser desenvolvida ou reutilizada e também
especificar marcos de entrega dos módulos do sistema, se for o caso. Por sua natureza, essa visão é
exclusiva dos analistas, desenvolvedores e integradores do projeto.

e) Visão da Implantação.

A visão de implantação refere-se à distribuição física do sistema através do conjunto de nós

do ambiente em que ele vai ser executado, incluindo distribuição física de processos e threads.

23
Prof. Sérgio Luiz Tonsig
3.2.1. Modelos de descoberta de Requisitos

Os modelos usados podem contribuir para a descoberta de requisitos ainda não identificados.
Por exemplo, um caso de uso pode levar ao desenho de uma interface (tela) e, ao realizar o mockup
da mesma, descobrir-se atributos que não foram contemplados pelo diagrama de classes.

Figura 20 – Mockup de Tela.

Na figura 20, vê-se um mockup de tela de “Cadastrar Cursos”. Pode ocorrer que, aquele
campo “Qtde Vagas” não tivesse sido descoberto antes de se fazer o modelo da tela. Então essa
atividade acaba sendo relevante para descoberta de novos atributos.

3.2.2. Requisitos funcionais e não funcionais.

Os processos de modelagem em todas as suas visões podem também ajudar a descobrir

requisitos funcionais e não funcionais e não funcionais; que são cruciais ao desenvolvimento de um
sistema de informações.

Os requisitos funcionais, são aqueles diretamente ligados a funcionalidade do software,

descrevem as funções que o software deve executar, como por exemplo:

 O software deve permitir o cadastro de clientes;

 O software deve permitir a geração de relatórios sobre o desempenho de vendas no
semestre;
 O software deve permitir o pagamento das compras através de cartão de crédito.

24
Prof. Sérgio Luiz Tonsig
 Requisitos não funcionais, são recursos indiretos ou restrições necessárias ao sistema que
será desenvolvido, como por exemplo:

 Necessidade de software/hardware para backup

 Necessidade de antivírus
 A consulta de entregas deve estar na web e oferecer uma resposta em menos de 2
segundos.

Atualmente a engenharia de requisitos cuida dos aspectos de criação e acompanhamento da

evolução dos requisitos em sistemas. Isso é possível através da chamada “gestão de configuração”,
que usa mecanismos como o git, gogs, gigbucket, phabricator, etc.

Figura 21 – Engenharia de Requisitos.

25
Prof. Sérgio Luiz Tonsig
4. Criando Diagramas com UML

A UML permite a criação de tipos diferentes de modelo; isto é, perspectivas diferentes de um

mesmo sistema. É empregada para a visualização, a especificação, a construção e a documentação
de artefatos que façam uso de sistemas de software. Abrange todas as visões necessárias ao
desenvolvimento e implantação de sistemas, desde sistemas de informação corporativos, aplicações
baseadas em Web, aplicações para dispositivos móveis, automação, até sistemas complexos
embutidos de tempo real.

Com a UML é possível obter-se a representação conceitual e física do sistema, gerando uma
documentação da arquitetura e todos os seus detalhes. A construção de artefatos visuais pode gerar
modelos precisos, sem ambiguidades, em função de que por trás de cada símbolo empregado existe
uma semântica bem definida.

No início da década de 90, várias propostas de métodos orientados a objeto para a análise
surgiram no mercado. Mas não havia um padrão.

Nesse período haviam três amigos que eram pesquisadores e profissionais na área de TI, cada
qual, tinha criado seu próprio método orientado a objetos para análise. Então, Grady Booch, Ivar
Jacobson e James Rumbaugh resolveram unificar suas propostas e, criaram uma empresa chamada
Rational Software Corporation (que hoje pertence a IBM). Depois de certa de um ano de trabalho, os
amigos lançaram para o mercado, em outubro de 1995, o esboço da versão 0.8 do Unified Process.3

Paralelamente a esse episódio, havia uma organização não governamental, a OMG4 (Object
Management Group), que lançou um desafio ao mercado, no sentido de padronizar um método
orientado a objetos para análise. Dentre as propostas recebidas, a dos três amigos foi a vencedora e,
em setembro de 1997, foi oficializada com o nome de UML5 (Unified Modeling Language – Linguagem
de Modelagem Unificada).

3
Veja toda história em https://pt.wikipedia.org/wiki/UML
4
O Object Management Group, ou OMG, é uma organização internacional que aprova padrões abertos para aplicações
orientadas a objetos. Visite: https://www.omg.org/
5
Veja mais em: http://uml.org/ e https://www.omg.org/spec/UML/About-UML/

26
Prof. Sérgio Luiz Tonsig
 Figura 02 – História da UML

4.1. Visão Externa – Casos de Uso

O diagrama de casos de uso corresponde a uma visão externa do sistema e representa

graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem como
objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com que
funcionalidades do sistema, ou seja, a finalidade de um diagrama de caso de uso é apresentar um
tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras
segundo as quais eles as utilizam.
A notação utilizada para ilustrar atores em um diagrama de caso de uso é a figura de um
boneco, com o nome do ator definido abaixo dessa figura. Vale ressaltar que um ator nem sempre é
um ser humano. É qualquer elemento externo que interage com o sistema (pessoas, organizações,
outros sistemas, equipamentos).
Para representar casos de uso, utilizamos uma elipse, com o nome do caso de uso dentro da
elipse, ou abaixo dela.

27
Prof. Sérgio Luiz Tonsig
Figura 22 – Diagrama de Casos de Uso.

28
Prof. Sérgio Luiz Tonsig
Referências Bibliográficas

ALVES, R. Filosofia da Ciência: Introdução ao Jogo e suas Regras. Brasiliense, 14ª. Ed., São Paulo, 1991.
BERTALANFFY, L. V. Teoria Geral de Sistemas. Vozes, Petrópolis, Rio de Janeiro, 1977.
CHIAVENATO, I. Teoria Geral da Administração. Campus, 5ª. Ed., São Paulo, 1999.
FERREIRA, A.B.H. Minidicionário da Língua Portuguesa. Nova Fronteira, Rio de Janeiro, 1993.
FILHO, W.P.P. Engenharia de Software. LTC, 4ª. Ed., Volume 1, 2019. E-Book.
FILHO, W.P.P. Engenharia de Software. LTC, 4ª. Ed., Volume 2, 2019. E-Book.
LARMAN, C. Utilizando UML e Padrões. BookMan, 3ª. Ed., Porto Alegre, 2007. E-Book

PRESSMAN, R.; MAXIM, B. Engenharia de Software – Uma abordagem profissional. BookMan, 8ª Ed.,
2016. E-Book.
SOMMERVILLE, I. Engenharia de Software. Pearson, 9ª. Ed, São Paulo, 2011.
TONSIG, S.L. Engenharia de Software – Análise e Projeto de Sistemas. Ciência Moderna, 2ª.Ed., Rio
de Janeiro, 2008.

29
Prof. Sérgio Luiz Tonsig