Apostila de MD2 Vers2

Governo do Estado do Rio de Janeiro
Secretaria de Estado de Ciência, Tecnologia e Inovação

Fundação de Apoio à Escola Técnica -FAETEC
Escola Técnica Estadual Maria Mercedes Mendes Teixeira – ETEMMMT
Apostila de Modelagem de Dados 2 Professor Evaldo Sousa
A natureza dos sistemas

A noção de sistemas e subsistemas pode ser considerada, hoje, como senso comum.
No entanto, através de um melhor conhecimento das características básicas de um sistema, de
seus pontos fundamentais e da natureza dos sistemas podemos melhor utilizar esse
ferramental indispensável para entendimento e modelagem de sistemas complexos.
A área de Sistemas de Informação foi fortemente influenciada pelos conceitos da Teoria
Geral dos Sistemas. Existem vários livros que tratam inicialmente dos conceitos de TGS.
Existem vários pontos chaves relativo ao tema.
1. Definição:
“Um conjunto de partes inter-relacionadas que trabalham na direção de um objetivo.”
2. Contextualização:
“Todo sistema é um subsistema de um sistema maior”
3. Classificação:
“Os sistemas podem ser classificados quanto à sua: natureza (natural, artificial), origem
(concreto, abstrato) e tipo (aberto, fechado).”
4. Características Básicas:
“Os sistemas têm propósito, são afetados pela globalidade e sofrem diversos”.
5. Conceitos fundamentais:
a. Limites:
Talvez esse seja um dos pontos mais difíceis de ser definido, isto é qual a fronteira de um
sistema? Como delimitar o que está dentro ou fora do sistema.
b. Interfaces:
A maneira como os subsistemas se relacionam através de entradas e saídas.
c. Pontos de Vista:
Todo sistema pode ser entendido ou observado de diferentes ângulos ou pontos de vista. Um
sistema pode ser influenciado por pontos de vista.
d. Nível de Abordagem (abstração):
Todo sistema tem um nível de detalhe. O importante é assegurar que o nível de detalhe
utilizado é condizente com o propósito do sistema.
e. Hierarquia:
A pedra fundamental da TGS na luta com a complexidade. A ideia de dividir um problema
grande (sistema) em problemas menores (subsistemas) é essencial a ideia de sistemas.
Sistema = conjunto de pessoas, máquinas e métodos organizados de modo a cumprir
um certo nº de funções específicas. Na verdade, quase tudo aquilo com que temos contato em
nossa vida, ou é um sistema ou um componente de um sistema ( ou ambas as coisas ).
Tipos de sistemas
• Sistemas naturais (não feitos por pessoas)
•Sist. físicos: estelares; geológicos,Sist. vivos: abrangem animais e plantas.
• Sistemas feitos pelo homem
Sist. social (leis), sist. de transportes, manufatura (fábricas), sist. financeiro.
FAETEC
evaldo.sousa@prof.etemmmt.faetec.rj.gov.br
*
Alguns são totalmente computadorizados; e outros em parte.Por
que automatizar?
• Custo
•Mais barato a execução manual
• Conforto
•Tamanho calor e ruído dos computadores
• Segurança
•Proteção de dados confidenciais
• Manutenibilidade
•Ninguém consegue efetuar modificações
• Política
Sistemas automatizados
Sist. feitos pelo homem, que interagem com ou são controlados por um ou mais
computadores.
• Componentes:
Hardware (hw): CPU, impressoras, Software (sw): Sist. Operacional, B.D
Usuários, programadores, analistas.
Dados: informações armazenadas.
Procedimentos: instruções para operação do sistema.
Divisão dos sistemas automatizados
1. On-line
Os dados são introduzidos no sist. proc. e dele recebidos remotamente.
Interação com o computador através de terminais (computador distante).
dados armazenados são rapidamente acessados e/ou modificados.
Exemplo: Compra de passagem aérea.
2. Tempo-real
Sistema que deve responder com suficiente rapidez (ms) ou o ambiente ficará fora de
controle.
Exemplos:
Processos da indústria química; caixa automático; orientação de mísseis; monitoração de
pacientes.
3. Sistemas de apoio a decisão
Analisar a missão da empresa.
Informações mais gerais sobre a situação do mercado. Histórico.
Fornece informações relevantes para os gerentes tomarem as decisões.
Criam e atualizam os dados exigidos pelos sistemas de nível mais elevado.
Exemplo: BI
4. Sistemas baseados no conhecimento
Sistemas especialistas têm embutido o conhecimento e a capacidade que o permitirão
funcionar como especialista. Uso de técnicas de Inteligência Artificial.
Exemplos:
FAETEC
evaldo.sousa@prof.etemmmt.faetec.rj.gov.br 2
Diagnóstico médico; avaliação eletrônica.

Características dos sistemas
Quanto mais especializado, menos capaz de se adaptar a circunstâncias diferentes.
Quanto maior, mais recursos destinados à manutenção: verificar erros, segurança,
documentação.
Sempre fazem parte de sistemas maiores e podem ser divididos.
Sistemas crescem. Inclusão de mais dados, funções e usuários.
Importância da Modelagem
Um modelo é uma simplificação da realidade.

Construímos modelos para compreender melhor o sistema que estamos desenvolvendo.
Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja.
Os modelos permitem especificar a estrutura ou o comportamento de um sistema.
Os modelos proporcionam um guia para a construção do sistema.
Os modelos documentam as decisões tomadas.
Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua
totalidade.
Para se construir uma casa ou um prédio de qualidade, é essencial fazer um
planejamento detalhado, com a finalidade de pensar sobre as formas de construção, fazer
estimativas de tempo e material para a realização desse projeto.
O desenvolvimento de um software de qualidade é semelhante a este processo, pois

também se trata de uma questão de arquitetura e ferramentas.
Softwares malsucedidos têm falhas específicas de cada um, mas todos os projetos
bem-sucedidos são semelhantes em diversos aspectos. Um dos elementos que contribuem
para o sucesso de um software é a utilização da modelagem.
Para fazer bons modelos deve-se utilizar uma linguagem de modelagem que seja
dotada de diagramas que permitam a representação de sistemas simples ou complexos sob as
diferentes visões, pois isso facilita o entendimento e padroniza a comunicação e a organização
do problema.
A Modelagem do Sistema
A UML é usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange
sempre qualquer característica de um sistema em um de seus diagramas e é também aplicada
em diferentes fases do desenvolvimento de um sistema, desde a especificação da análise de
requisitos até a finalização com a fase de testes.
O objetivo da UML é descrever qualquer tipo de sistema, em termos de diagramas
orientados a objetos. Naturalmente, o uso mais comum é para criar modelos de sistemas de
software, mas a UML também é usada para representar sistemas mecânicos sem nenhum
software. Falaremos sobre UML um pouco mais a frente.
Aqui estão alguns tipos diferentes de sistemas com suas características mais comuns.
Sistemas de Informação: Armazenar, pesquisar, editar e mostrar informações para os

usuários. Manter grandes quantidades de dados com relacionamentos complexos,que
FAETEC
são guardados em bancos de dados relacionais ou orientados a objetos.

Sistemas Técnicos: Manter e controlar equipamentos técnicos como de
telecomunicações, equipamentos militares ou processos industriais. Eles devem possuir
interfaces especiais do equipamento e menos programação de software deque os
sistemas de informação. Sistemas Técnicos são geralmente sistemas real-time.
Sistemas Real-time Integrados: Executados em simples peças de hardware integrados a
telefones celulares, carros, alarmes etc. Estes sistemas implementam programação de
baixo nível e requerem suporte real-time.
Sistemas Distribuídos: Distribuídos em máquinas onde os dados são transferidos
facilmente de uma máquina para outra. Eles requerem mecanismos de comunicação
sincronizados para garantir a integridade dos dados e geralmente são construídos em
mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI.
Sistemas de Software: Definem uma infra-estrutura técnica que outros softwares
utilizam. Sistemas Operacionais, bancos de dados, e ações de usuários que executam
ações de baixo nível no hardware, ao mesmo tempo em que disponibilizam interfaces
genéricas de uso de outros softwares.
Sistemas de Negócios: descreve os objetivos, especificações (pessoas, computadores
etc.), as regras (leis, estratégias de negócios etc.), e o atual trabalho desempenhado
nos processos do negócio.
É importante perceber que a maioria dos sistemas não possui apenas uma destas
características acima relacionadas, mas várias delas ao mesmo tempo. Sistemas de
informações de hoje, por exemplo, podem ter tanto características distribuídas como real-
time. E a UML suporta modelagens de todos estes tipos de sistemas.
Existem diversas ferramentas disponíveis para a modelagem do sistema de
dados:Astah, StarUML, etc.( mais a frente conheceremos mais algumas).
Para a modelagem do sistema, na nossa aula utilizaremos uma ou mais ferramentas de
modelagem.
Modelos de dados
Modelos de dados refletem de uma forma gráfica (e lógica) a base de dados de um
sistema, seus relacionamentos, entidades, chaves e tudo aquilo que é referente aos dados em
si.
Este modelo, junto com o dicionário de dados, é peça fundamental para o
desenvolvimento de um sistema, sendo inclusive pensado e criado ANTES do início do
desenvolvimento. Um bom modelo de dados bem pensado e bem estruturado não impacta
somente em um bom código, mas também na performance da aplicação com um todo e na
redução de horas de desenvolvimento equivocado.
Para criá-lo são utilizadas ferramentas de modelagem de dados, as quais geram de

forma gráfica as tabelas, índices, relacionamentos e tudo aquilo que tem a ver com a base de
dados em si, podendo ser criados por meio de engenharia reversa ou ainda baseando-se nas
necessidades do aplicativo que está sendo desenvolvido.
Princípios e Histórico da Modelagem
O rápido crescimento da capacidade computacional das máquinas resultou na
FAETEC
demanda por sistemas de software cada vez mais complexos. O surgimento de sistemas de
software mais complexos resultou na necessidade de reavaliação da forma de se desenvolver
sistemas. Consequentemente, as técnicas utilizadas para a construção de sistemas
computacionais têm evoluído de forma impressionante, principalmente na modelagem de
sistemas Na primeira metade da década de 90 surgiram várias propostas de técnicas para
modelagem de sistemas segundo o paradigma orientado a objetos.
Houve uma grande proliferação de propostas para modelagem
orientada a objetos: diferentes notações gráficas para modelar uma mesma
perspectiva de um sistema. Cada técnica tinha seus pontos fortes e fracos. Percebeu-se a
necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado
amplamente. Alguns esforços foram feitos nesse sentido de padronização, o
principal liderado pelo “três amigos”. Surge a UML (Unified Modeling Language) em 1996
como a melhor candidata para ser linguagem “unificadora”. Em 1997, a
UML é aprovada como padrão pelo OMG. Desde então, a UML tem tido grande aceitação pela
comunidade de desenvolvedores de sistemas. É uma linguagem ainda em desenvolvimento.
Atualmente na versão 2.3.
Atividades de Desenvolvimento de Um Software

Levantamento de requisitos; Análise de requisitos; Projeto; Implementação; Testes;
Implantação.
Concepção - Contrato e Levantamento de requisitos;
Elaboração - Análise de requisito e Projeto;
Construção - Implementação e Testes;
Transição – Implantação
Participantes de um processo de Desenvolvimento de Software
Gerentes de projeto - Responsável pela gerência ou coordenação das atividades

necessárias à construção do sistema.
Analistas - Responsável por entender as necessidades do dos clientes e repassar esse
entendimento aos desenvolvedores do sistema.
Projetistas - Tem como funções especificar soluções para os problemas resultantes da
análise.
Arquitetos de software - Tem como função elaborar a arquitetura do sistema como um
todo.
Programadores - Responsável pela implementação do sistema.
Clientes - Indivíduo (ou grupo) para o qual o sistema é construído.
Avaliadores de qualidade - Asseguram a adequação do processo de desenvolvimento e
do produto de software sendo desenvolvido aos padrões de qualidade estabelecidos.
Modelagem Orientada a objetos
A Orientação a Objetos é um padrão de desenvolvimento de software baseada em

Classes. Nesse padrão as classes são como uma forma para criação de objetos, os quais serão
utilizados no sistema. Nesta modalidade de programação, os objetos trocam “mensagens” e
são utilizados para realizar ações executadas na memória do computador, enquanto às classes
resta apenas definir as características e ações destes objetos. Quando um software é
desenvolvido com o conceito de orientação a objetos, normalmente são criados modelos, que
serão uteis para representar o sistema de forma rápida e objetiva. Estes modelos são criados
antes da codificação e representam, de forma detalhada e por meio de diagramas, todo o
software que será implementado.Modelo de objetos
FAETEC
O modelo de objetos descreve a estrutura estática de um sistema, isto é, a estrutura

de seus objetos e os relacionamentos existentes entre eles em um determinado instante de
tempo, os atributos e as operações que caracterizam cada classe de objetos.
Este é o mais importante dos três modelos porque é o que melhor representa a realidade,
sendo mais adaptável às modificações.
Os modelos baseados em objetos apresentam uma intuitiva representação gráfica e são úteis
para a comunicação com os clientes e para a documentação da estrutura do sistema.
Modelo dinâmico
O modelo dinâmico descreve os aspectos de um sistema examinado as modificações

ocorridas nos seus objetos e seus relacionamentos em relação ao tempo.
Os principais conceitos da modelagem dinâmica são os eventos, que representam os
estímulos externos, e os estados, que representam o intervalo entre esses eventos e
especificam o contexto em que são interpretados.
Paradigma da Orientação a Objetos

A programação orientada a objeto s representa uma mudança no enfoque da programação, na
forma como os sistemas eram vistos até então. Representa uma quebra de paradigma,
revolucionando todos os conceitos de projetos e desenvolvimento de sistemas existentes.
“Paradigma é um conjunto de regras que estabelecem fronteiras e descrevem como resolver

os problemas dentro dessas fronteiras. Os paradigmas influenciam nossa percepção; ajudam-
nos a organizar e a coordenar a maneira como olhamos o mundo”
O enfoque tradicional para o desenvolvimento de sistemas é, por consequência, para a

programação, baseia-se no conceito de que um sistema é um conjunto de programas inter-
relacionados que atuam sobre um determinado conjunto de dados que se deseja manipular de
alguma forma para obter os resultados desejados. O enfoque da modelagem de sistemas por
objetos procura enxergar o mundo como um conjunto de objetos que interagem entre si e
apresentam características e comportamentos próprios representados por seu atributos e suas
operações. Os atributos estão relacionados aos dados e as operações, aos processos que um
objeto executa.
Assim, supondo que deseje desenvolver um sistema de controle de estoque para uma
empresa, procura-se identificar os objetos que relacionados ao sistema , como os produtos, os
FAETEC
pedidos de compras, os recibos, as pessoas, etc. , conforme está detalhado a seguir . Pode-se
dizer que é possível modelar, por meio de orientação a objetos, um setor, um departamento e
até uma empresa inteira.
Esse enfoque justifica-se, de forma resumida, pelo fato de que os objetos existem na natureza
muito antes de haver qualquer tipo de negócio envolvido ou qualquer tipo de sistemas para
controla-los. Equipamentos, pessoas , materiais, produtos, peças, ferramentas, combustíveis,
etc.
O que é um objeto
Um objeto é uma extensão de conceitos de objeto do mundo real, em que se podem ter coisas
tangíveis, um incidente (evento ou ocorrência) ou uma interação (transação ou contrato).
Por exemplo, em um sistema acadêmico em que João é um aluno objeto e Carlos é um

professor objeto que ministra aulas objeto da disciplina objeto algoritmos, para que João
possa assistir às aulas da disciplina do prof. Carlos, ele precisa fazer uma matrícula objeto no
curso objeto de computação.
Têm-se as ocorrências de objetos citados:
Tangíveis: aluno e professor:
FAETEC
Incidente: Curso, disciplina, aluno:

Interação: Matricula:
A identificação dos objetos em um sistema depende do nível de abstração de quem faz a
modelagem, podendo ocorrer identificação de diferentes tipos de objetos e diferentes tipos de
classificação desses objetos. Não existe um modelo definitivamente correto: isso vai depender
de quem faz a modelagem e de processos sucessivos de refinamento , até que possa encontrar
um modelo adequado a sua aplicação.
Conceito de Classes
Uma classe é uma coleção de objetos que podem ser descritos por um conjunto básico
de atributos e possuem operações semelhantes. Quando um objeto é identificado com atributos
e operações semelhantes em nosso sistema, diz-se que pode ser agrupado em classes. Todos os
objetos são instâncias de classes, onde a classe descreve as propriedades e comportamentos
daquele objeto. Objetos só podem ser instanciados de classes. Usam-se classes para classificar
os objetos que identificamos no mundo real. Tomando como exemplo Charles Darwin, que usou
classes para classificar os animais conhecidos, e combinou suas classes por herança para
descrever a "Teoria da Evolução". A técnica de herança entre classes é também usada em
orientação a objetos.
Uma classe pode ser a descrição de um objeto em qualquer tipo de sistema – sistemas
de informação, técnicos, integrados real-time, distribuídos, software etc. Num sistema de
software, por exemplo, existem classes que representam entidades de software num sistema
operacional como arquivos, programas executáveis, janelas, barras de rolagem, etc.
Identificar as classes de um sistema pode ser complicado, e deve ser feito com bastante
cautela no domínio do problema a que o software modelado se baseia. As classes devem ser
retiradas do domínio do problema e serem nomeadas pelo que elas representamno sistema.
Quando procuramos definir as classes de um sistema, existem algumas questões que podem
ajudar a identificá-las:
• Existem informações que devem ser armazenadas ou analisadas? Se existir alguma informação
que tenha que ser guardada, transformada ou analisada de alguma forma, então é uma possível
candidata para ser uma classe.
• Existem sistemas externos ao modelado? Se existir, eles deverão ser vistos como classes pelo
sistema para que possa interagir com outros externos.
• Existem classes de bibliotecas, componentes ou modelos externos a serem utilizados pelo sistema
modelado? Se sim, normalmente essas classes, componentes e modelos conterão classes
candidatas ao nosso sistema.
• Qual o papel dos atores dentro do sistema? Talvez o papel deles possa ser visto como classes, por
exemplo, usuário, operador, cliente e daí por diante.
Em UML as classes são representadas por um retângulo dividido em três compartimentos:
o compartimento de nome, que conterá apenas o nome da classe modelada, o de atributos, que
possuirá a relação de atributos que a classe possui em sua estrutura interna, e o compartimento
de operações, que serão os métodos de manipulação de dados e de comunicação de uma classe
com outras do sistema. A sintaxe usada em cada um destes compartimentos é independente de
qualquer linguagem de programação, embora pode ser usadas outras sintaxes como a do C++,
Java, e etc.
Nome da Classe
Cliente
Nome: String
Atributos
Idade: Num
FAETEC Criar ( )
Destruir( )
Operações
Objetos
Um objeto é um elemento que podemos manipular acompanhar seu comportamento,

criar, destruir etc. Um objeto existe no mundo real. Pode ser uma parte de qualquer tipo de
sistema, por exemplo, uma máquina, uma organização, ou negócio. Existem objetos que não
encontramos no mundo real, mas que podem ser vistos de derivações de estudos da estrutura
e comportamento de outros objetos do mundo real.
Em UML um objeto é mostrado como uma classe só que seu nome (do objeto) é
sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do nome da
classe.
Pablo Barros :Cliente Nome do Objeto
Nome: “Pablo Barros”
Apostila de Modelagem de Dados I

Site : www.professorinfoevaldo.tk Email : professorinfoevaldo@
Atributos Professor Evaldo Sousa
Idade: 20 gmail.com
Operações
Criar ( )
Destruir( )
Mensagens
Para que uma operação em um objeto seja executada deve haver um estímulo a esse
objeto. Se um objeto for visto como uma entidade ativa que representa uma abstração de algo
do mundo real, então faz sentido dizer que tal objeto pode responder a estímulos a ele enviados.
Independente da origem do estímulo, quando ele ocorre diz-se que o objeto em questão está
recebendo uma mensagem requisitando que ele realize alguma operação.
FAETEC
O papel da abstração na orientação a objetos

Uma abstração é qualquer modelo que inclui os aspectos mais importantes essenciais
de alguma coisa, ao mesmo tempo em que ignora os detalhes menos importantes. Abstrações
permitem gerenciar a complexidade e concentrar a atenção nas características essenciais de um
objeto.
Encapsulamento
Objetos possuem comportamento. O termo comportamento diz respeito a operações
realizadas por um objeto e também ao modo pelo qual essas operações são executadas. O
mecanismo de encapsulamento é uma forma de restringir o acesso ao comportamento interno
de um objeto. Um objeto que precise da colaboração de outro objeto para realizar alguma tarefa
simplesmente envia uma mensagem a este último.
Polimorfismo
Associado ao conceito de Herança, o polimorfismo permite que um objeto assuma um
comportamento diferente daquele definido na sua classe. Polimorfismo significa a capacidade
FAETEC
de assumir muitas formas. Como exemplo temos uma classe veículos que possui as subclasses
utilitários, esporte,passeio e passageiros e a operação dar partida. Tomando-se a operação dar
partida como exemplo, pode-se dizer que para dar partida em um veículo de passeio e em um
veículo utilitário, pode-se precisar executar tarefas diferentes. Muitas vezes, dependendo do
tipo de motor que equipa o veículo e do combustível utilizado, o processo muda
significativamente. Considerando-se assim que a operação dar partida precisa ser adaptada para
a classe utilitário, reescrevem-se as tarefas para essa operação, que passará a responder de
forma diferente apenas para essa classe e para os objetos instanciados por ela.
Herança
A herança é outra forma de abstração utilizada na orientação a objetos. A herança pode

ser vista como um nível de abstração acima da encontrada entre classes e objetos, na herança
classes semelhantes são agrupadas em hierarquias. Cada nível de uma hierarquia pode ser visto
como um nível de abstração. Cada classe em um nível da hierarquia herda as características.
Esse mecanismo facilita o compartilhamento de comportamento comum entre um conjunto de
classes semelhantes.
FAETEC
Ciclo de Vida de um Software
Análise de Requisitos
Esta fase visa identificar o tipo de serviço de processamento de dados a ser executado
(manutenção de um software existente ou a criação de um outro), os objetivos a serem
alcançados, recursos e prazos necessários para a execução do projeto.
O Resultando é um documento denominado Anteprojeto, contendo o modelo lógico
preliminar do software. A aprovação deste documento pelo usuário torna-se pré-requisito para
a continuidade do trabalho.
Projeto Lógico
Nesta fase o objetivo é a especificação detalhada dos elementos do software a nível
lógico. Além disso, deve tratar da especificação detalhada dos procedimentos externos ao
computador, tais como:
Captação das informações;
Preparo e envio para processamento;
Crítica e correções;
Distribuição das saídas.
O produto é um documento denominado Manual do Software - Parte I - Projeto
Lógico, que deverá ser submetido ao usuário para análise e aprovação.
Projeto Físico
Tendo como base o Projeto Lógico, o objetivo nesta fase é o de detalhar os elementos
do software a nível físico.
O Produto é um documento denominado Manual do Software - Parte II - Projeto Físico,
que conterá a especificação técnica completa do software, visando a sua implementação.
Implementação
O objetivo desta fase é o desenvolvimento e simulação do software especificado no
Projeto Físico.
O resultado são os programas fontes, devidamente testados. Estes, por sua vez, devem
ser entregues ao usuário via disquetes.
Implantação
Tem como objetivo o treinamento do usuário, a conversão/inicialização de arquivos e
a implantação do software para produção.
Nesta fase, é elaborado e entregue o Manual do Usuário, assim como o Termo de
Encerramento do Desenvolvimento do Software, onde o analista ou empresa desenvolvedora
declara que o software, uma vez implantado, está entregue e considerado, aceito: devendo o
mesmo entrar no período de garantia.
Operação
Nesta Fase são executadas as atividades de produção do software pelo usuário, com
acompanhamento inicial da execução das rotinas, avaliação da performance, pequenos ajustes
e análise de resultados.
O produto é um relatório descritivo dos problemas encontrados pelo usuário e as
soluções adotadas, e a documentação do software, como um todo, devidamente revisada.
FAETEC
Ciclo de Vida Vantagens Desvantagens
 Fortemente documentado  Improdutivo quanto ao tempo

Modelo em FASE  Sua visão Sequencial não
 Visa Alta Qualidade corresponde ao mundo real
 Enfatiza metas e pontos de
revisão
 Facilidade de percepção por  O risco do protótipo passar o

Modelo em Protótipo parte do usuário sistema em produção
 Não exige grande  No descarte do protótipo

quantidade de detalhamento pode se perder as
especificações de requisitos.
 Permite a resolução do  Continua dando mais ênfase a

Modelo em Espiral sistema por partes parte funcional
 Melhora o tempo de
implementação do sistema
 Manutenção da  Necessidade de um conversor

Modelo Automatizado especificação de requisitos automático
ao invés de código
 Seu nível de abstração
 Maior facilidade de depende da conversão
interação por parte do
usuário
 Permite criar facilmente

protótipos
Exemplo de Modelo de Sistema em espiral
FAETEC
Etapas de um ciclo
Introdução a UML
A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada). É uma

linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de
orientação a objetos. Essa linguagem se tronou nos últimos anos a linguagem padrão de
modelagem de Software adotada internacionalmente pela indústria de engenharia de Software.
A UML não é uma linguagem de programação, mas uma linguagem de modelagem, cujo
objetivo é auxiliar a definir as características do Software, tais como seus requisitos, seu
comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas
necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser
implantado.Todas essas características são definidas por meio da UML antes de o Software
começar a ser realmente desenvolvido.
Breve Histórico
A UML surgiu da união de três metodologias de modelagem: O método de Booch, o
método OMT (Object Modeling Technique ) de Jacobson e o método OOSE (Object – Oriented
Software Engineering) de Rumbaugh.
Essas eram , até meados da década de 1990 as três metodologias de modelagem
orientada a objetos mais populares entre os profissionais da área de engenharia de Software.
O trabalho de Booch, Jacobson e Rumbaugh, conhecidos popularmente como os três
amigos, resultou no lançamento em 1996 da primeira versão da UML.
FAETEC
A linguagem de Modelagem
A UML é uma linguagem constituída de elementos gráficos ( visuais)utilizados na
modelagem que permitem representar os conceitos do paradigma da orientação
objetos.
Cada elemento gráfico possui uma forma predeterminada de desenhar o elemento e
uma semântica que definem o que significa o elemento e para que ele deva ser utilizado.
A UML é independente tanto de linguagem de programação quanto de processos de
desenvolvimentos. Isso quer dizer que pode ser utilizada para a modelagem de sistemas, não
importa qual a linguagem de programação será utilizada na implementação de sistema, ou qual
a forma ( processo) de desenvolvimento adotado.
Diagramas da UML
O objetivo dos diagramas é fornecer múltiplas do sistema a ser modelado, analisando-

o e modelando-o sob diversos aspectos, permitindo que cada diagrama complemente osoutros.
A utilização de diversos diagramas permite que falhas possam ser descobertas nos diagramas
anteriores, diminuindo a possibilidade da ocorrência de erros durante a fase de
desenvolvimento do Software.
Resumo dos diagramas da UML
Cada diagrama possui uma aba em seu canto superior esquerdo contendo um operador
e a descrição do diagrama. O operador serve para determinar qual o é o tipo de diagrama, assim
uc refere-se a Use Case Diagrama ( Diagrama de caso de uso); class a Class diagram ( Diagrama
de Classes); object, a Object diagram (Diagrama de objetos) ; sd, a Sequence diagram( Diagrama
de Sequência); STM , a state – Machine Diagram ( Diagrama de Máquina de Estados).
Modelos de Elementos
Os conceitos usados nos diagramas da UML são chamados de modelos de elementos.

Um modelo de elemento é definido com a semântica, a definição formal do elemento com o
exato significado do que ele representa sem definições duvidosas ou ambíguas e também define
sua representação gráfica que é mostrada nos diagramas da UML. Um elemento pode existir em
diversos tipos de diagramas, mas existem regras que definem que elementos podem ser
mostrados em que tipos de diagramas. Alguns exemplos de modelos de elementos são as
classes, objetos, estados, etc. Os relacionamentos também são modelos de elementos, e são
usados para conectar outros modelos de elementos entre si.
Diagramas
Os diagramas utilizados pela UML são compostos de 13(treze)diagramas estamos

falando da atual versão (UML 2.0), observando que a versão(UML 1.5) possuía apenas nove tipos
de diagrama:
Os diagramas da UML 2.0 são os seguintes:
Diagrama de Caso de Uso, de classes, de objeto, de estrutura composta, de sequencia, de
Comunicação(era conhecido como diagrama de colaboração), de Máquinas de estado, de atividade, de
interação geral, de componentes, de implantação, de pacotes e o de tempo. . Todos os sistemas possuem
FAETEC
uma estrutura estática e um comportamento dinâmico. A UML suporta modelos estáticos (estrutura
estática), dinâmicos (comportamento dinâmico) e funcional. A Modelagem estática é suportada pelo
diagrama de classes e de objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos
podem ser de associações, herança (generalização), dependência ou refinamentos.
Diagrama Caso de Uso
Este é o diagrama mais geral e informal da UML, sendo utilizado principalmente para
auxiliar no levantamento e análise de requisitos, em que são determinantes as necessidades dos
usuários e na compreensão do sistema como um todo. Ele consultado durante todacriação e
modelagem do sistema, servindo de base para todos os outros diagramas.
O diagrama de casos de uso apresenta uma linguagem simples e de fácil compreensão
para que os usuários possam ter uma ideia geral de como o sistema irá se comportar. Ele procura
identificar os atores( Usuários, outros softwares que interajam com o sistema ou até mesmo
algum Hardware especial), que utilizarão de alguma forma o software, bem como os serviços,
ou seja as opções que o sistema disponibilizará aos atores, conhecidos neste diagrama.
Os atores representam o papel de uma entidade externa ao sistema como um usuário,
um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a
comunicação com o sistema através dos casos de uso representando uma sequencia de ações
executadas pelo sistema e recebe do ator.
A figura abaixo mostra um exemplo de Caso de Uso
Diagrama de classes
FAETEC
Este é o diagrama mais utilizado e o mais importante da UML, servindo de

apoio para amaioria dos outros diagramas. Como o próprio nome diz, este diagrama
define a estrutura das classes utilizadas pelo sistema, determinando os atributos e
métodos possuídos por cada classe, além de estabelecer como as classes se
relacionam e trocam informações entre si.
A Figura abaixo mostra um exemplo de diagrama de classe.
Aprendendo UML
Diagrama de Casos de Uso
Este diagrama procura, por meios de uma linguagem simples, demonstrar o

comportamento externo do sistema, buscando apresentar o sistema por uma
perspectiva do usuário, demonstrando as funções e os serviços oferecidos e quais
usuários poderão utilizar cada serviço.
FAETEC
Atores
Os atores representam os papeis desempenhados pelos diversos usuários que poderão
utilizar ou interagir com os serviços e funções do sistema. Eventualmente um ator pode
representar algum hardware especial ou mesmo outro software que interaja com o sistema.
Assim, um ator pode ser qualquer elemento externo que interaja com o software. Os atores
são representados por um desenho de um boneco com sua descrição abaixo conforme
exemplo abaixo.
Supervisor Aluno Vendedor
Casos de usos
Os casos de usos referem-se a serviços, tarefas ou funções oferecidas pelo

sistema, como emitir um relatório ou cadastrar a venda de algum produto. São
utilizados para representar e documentar os comportamentos pretendidos para as
funções do sistema.
Abaixo um exemplo de Caso de uso.
Associações
As associações representam os relacionamentos entre os atores que

interagem com o sistema, entre os atores e os casos de uso ou entre os casos de uso
ou os relacionamentos entre os casos de uso e outros casos de uso.
O relacionamento entre casos de usos recebem nomes especiais, como
generalização, inclusão e extensão.
Uma associação entre um ator e um caso de uso, é representada por uma
reta ligando o ator ao caso de uso.
FAETEC
Especialização/Generalização
Este relacionamento é uma forma de associação entre casos de uso, na qual

existem dois ou mais casos de usos com características semelhantes, apresentando
pequenas diferenças entre si. Nesse caso, defini-se um caso com as características
de uso geral que são compartilhadas e então se relaciona aos outros casos de uso
em questão.
Exemplo de um caso de uso de Generalização
Neste exemplo temos três opções de abertura de conta muito semelhantes

entre si. Aberturas de conta comum, de conta especial e de conta poupança
possuem todas as características e requisitos próprios, o que justifica colocá-las
como generalização do caso de uso Abertura de Conta Comum, detalhando-se as
particularidades de caso de uso especializado em sua própria documentação.
FAETEC
Inclusão
Esta associação é utilizada quando existe uma situação ou rotina comum a mais de um
caso de uso. Quando isso ocorre, a documentação dessa rotina é colocada em um caso de uso
específico para que outros casos de uso se utilizem desse serviço, evitando-se descrever uma
mesma seqüência de passos em vários casos de uso. Os relacionamentos de inclusão indicam
uma obrigatoriedade, ou seja, quando um determinado caso de uso possui um relacionamento
de inclusão com outro, a execução do primeiro, obriga também a execução do segundo.
Uma associação de inclusão é representada por uma reta tracejada contendo uma seta
em uma de suas extremidades que aponta para o caso de uso incluído pelo caso de uso que o
incluiu. As associações de inclusão apresentam um estereótipo contendo o texto “<<include>>“,
tendo como objetivo dar um destaque especial a um componente ou relacionamento.
Exemplo de um Relacionamento de inclusão
Sempre que um saque ou depósito ocorre, ele deve ser registrado para fins histórico
bancário. Como as rotinas para registro de um saque ou um depósito são extremamente
semelhantes, colocou-se a rotina de registro em um caso de uso à parte, chamado Registrar
Movimento,que será executado obrigatoriamente sempre que os casos de uso Depósito ou
Saldo forem utilizados.
Extensão
Esta associação é utilizada para descrever cenários opcionais de um caso de uso, que
somente ocorrerão se uma determinada condição for satisfeita. As associações de extensão
possuem uma representação muito semelhante às associações de inclusão, sendo também
representadas por uma reta tracejada, diferenciando-se por possui um estereótipo contendo o
texto “<<extend>>” e pela seta apontar para o caso de uso que estende.
FAETEC
Restrição em Associação de Extensão
Restrições são compostas por um texto entre chaves e são utilizados para definir
validações, consistências, condições, etc., que devem ser aplicadas a um determinado
componente ou situação. Às vezes para não haver dúvidas quanto ao caso de uso entendido,
pode se acrescentar uma restrição à associação de extensão por meio de uma nota explicativa
,determinando a condição para que o caso de uso seja executado.
Exemplo:
Multiplicidade no diagrama de Casos de uso
A multiplicidade em uma associação entre um ator e um caso de uso basicamente

especifica o numero de vezes que um ator pode utilizar um determinado caso de uso.
Exemplo de Multiplicidades em Associações entre Atores e Casos de Uso.
Fronteira do Sistema
Uma fronteira de sistema identifica um classificador que contém um conjunto de casos

de uso. Uma fronteira de sistema permite identificar um subsistema ou mesmo um sistema
completo, além de destacar o que está contido no sistema e o que não está.
Documentações de Casos de Uso
A documentação de um caso de uso costuma descrever, por meio uma linguagem

bastante simples, a função em linhas gerais do caso de uso, destacando quais atores interagem
com ele, quais etapas devem ser executadas pelo ator e pelo sistema para que o caso de uso
FAETEC
execute sua função, quais parâmetros devem ser fornecidos e quais restrições e validações o
caso de uso deve possuir. O formato de documentação de um caso de uso é bastante flexível,
permitindo que se documente o caso de uso da forma que se considere melhor.
Exemplo de documentação de um caso de uso.
Nome do Caso de Uso Realizar Submissão
Caso de Uso Geral
Ator Principal Submissor
Atores Secundários
Resumos Este Caso de Uso descreve as etapas percorridas por um
autor para submeter um trabalho ao congresso.
Pré-condições O submissor precisa estar logado
Pós-condições
Ações do Ator Ações do Sistema
1. Solicitar opção de submissão

de trabalhos
2. Selecionar temas aceitos pelo Congresso.
3. Apresentar tela de submissão contendo os temas aceitose

os tipos de submissões (artigos, minicursos e palestras)
válidos
4. Selecionar tema
5. Consultar tema selecionado
6. Selecionar tipo de submissão
7. Informar dados de submissão
8.Anexar arquivo com o

trabalho a ser submetido
9. Confirma
10. Registrar submissão
11. Apresentar mensagem de trabalho submetido com

sucesso
FAETEC
1. Todos os campos são obrigatórios
Restrições Validações 2. É obrigatório anexar o arquivo do trabalho submetido
Neste exemplo o campo caso de uso geral foi deixado em branco, simplesmenteporque
o caso de uso documentado não o possui, uma vez que não é um caso de uso especializado a
partir de outro.
O Campo Ator secundário contém a descrição de outros atores que podem participar do
processo.
Os Campos pré-condições e pós-condições informam possíveis condições que devem ser

satisfeitas antes e depois de o caso de uso ser executado.
O campo restrições contém as consistências que devem ser validadas durante o

processo. As restrições também podem ser chamadas de regras de negócios.
Estudo de Caso
Procurando fornecer um exemplo mais concreto, iremos enfocar a modelagem de um

sistemas para controle de submissões de congresso, que deverá satisfazer as seguintes
condições (Iremos detalhar apenas as informações referentes a modelagem de casos de Uso.
Outras informações sobre os requisitos do sistema iremos detalhar quando estivermos
estudando o diagrama de classe)
• O sistema aceita submissões sobre diversos temas como Engenharia de softwares,

Banco de Dados, e Hipermídia, sendo necessário portanto manter um cadastro de todos
os temas aceitos.
• Um autor pode realizar muitas submissões. Uma submissão pode se constituir em um

artigo, um minicursos ou uma palestra. As submissões podem ser realizadas pela
internet. Ao acessar a página de submissão o autor pode se logar, realizar uma
submissão ou verificar a situação de trabalhos já submetidos ;no entanto, para utilizar
os dois últimos serviços , ele deverá antes executar o primeiro.
• Um submissor (autor) deve se registrar no sistema antes de poder se logar, Se já estiver

registrado deverá então logar-se , informando se o nome – login e senha.
• Toda submissão precisa ser avaliada por uma comissão de três avaliadores, responsável
por analisá-la e fornecer notas. Um avaliador pode avaliar muitas submissões, as quais
são aprovadas de acordo com as maiores notas gerais. A nota geral de uma submissão
será o resultado da média de todas as notas das avaliações de cada submissão as
melhores notas de cada tema e tipo serão consideradas aprovadas. É necessário manter
um cadastro de todos os avaliadores do congresso.
• É responsabilidade do coordenador do evento definir quais serão os avaliadores das

diferentes submissões. É também responsabilidade do coordenador notificar os
submissores sobre a aceitação ou não de suas submissões no evento.
FAETEC
• O coordenador pode emitir o relatório das avaliações sempre que quiser; no entanto, a
partir do momento em que selecionar a opção notificar submissores estes serão
avisados se suas submissões foram ou não aprovadas.
• Sendo ou não aprovadas, uma submissão pode ou não receber comentários dos
avaliadores referentes a possíveis alterações necessárias antes de a submissão ser
publicada / disponibilizada no congresso ou conter informações relativas ao porquê da
não aprovação do trabalho pelo avaliador.
• O submissor pode consultar o estado de suas submissões, ou seja, se elas estão ainda
sob avaliação, foram aprovadas ou reprovadas. Um submissor pode também verificar
os possíveis comentários dos avaliadores a respeito de uma submissão específica.
O problema descrito anteriormente, conforme pode ver nesse exemplo utilizará uma
fronteira de sistema, separando os atores, que na verdade, não fazem realmente parte do
sistema, apenas interagem com ele. Os atores identificados foram: Submissor, digitador,
avaliador e coordenador.
O ator denominado submissor pode utilizar os serviços de realizar login submissor, auto-
registrar,realizar submissão, verificar submissão e verificar comentários. Observe que o
submissor somente poderá utilizar o caso de uso auto-registrar a partir do caso de uso realizar
login, e assim mesmo, se ainda não estiver registrado, conforme demonstra o relacionamento
de extensão entre os dois casos de uso. O Mesmo acontece com o caso de uso verificar
comentários, que só pode ser utilizado a partir do caso de uso verificar submissões. Os casos
de uso realizar submissão e verificar submissão só podem ser utilizados depois que o submissor
tiver se logado, no entanto, como não são extensões do caso de uso realizar login, eles foram
modelados de forma independente, devendo possuir em sua documentação uma restrição
informando que o submissor precisa estar logado antes de executá-los.
Na Descrição do Diagrama você poderá observar também as seguintes questões.
O ator digitador é responsável somente por executar serviços simples como manter o
cadastro dos avaliadores e dos temas válidos no congresso.
O ator avaliador pode somente informar as notas de suas avaliações a respeito das
submissões que lhe foram atribuídas. Eventualmente um avaliador pode querer realizar algum
comentário com relação a uma avaliação sendo este o motivo da associação de extensão entre
os casos de uso manter avaliações e manter comentários.
O ator coordenador deve poder manipular o registro de submissões definindo quem

irá avaliá-las e informando se foram aprovadas ou não. Além disso, é responsabilidade do
coordenador notificar a aprovação ou não de uma submissão a um submissor. Finalmente o
coordenador pode a qualquer momento solicitar o relatório de avaliações que apresentará a
lista de submissões de um determinado tema por ordem da média de notas recebidas.
FAETEC
Descrevendo o Estudo de Caso no Diagrama de Casos de Uso
FAETEC
2-Diagrama de classe
O diagrama de classes é o mais utilizado da UML. Seu objetivo é permitir a visualização

das classes utilizadas pelo sistema e como estas se relacionam. Esse diagrama apresenta uma
visão estática de como as classes estão organizadas, preocupando-se em definir sua estrutura
lógica.
Nesse diagrama, a abstração de cada classe com seus atributos e métodos

individualmente corresponde à modelagem de vocabulário, em que são definidas as classes que
farão parte do diagrama, ao passo que a definição de como as classes se relaciona e colaboram
para a execução de um determinado processo corresponde à modelagem de colaboração. Um
modelo de colaboração normalmente não enfoca os relacionamentos entre todas as classes que
são abstraídas no projeto, apenas as que colaboram de alguma maneira para a execução de um
processo específico.
Um diagrama de classes pode ser utilizado para definir o modelo lógico de um banco
de dados, quando se assemelha aos antigos modelos entidade-relacionamento. Na verdade, o
diagrama de classes foi propositalmente projetado para ser uma evolução do modelo. E-R. No
entanto, deve ficar bem claro que no diagrama de classes não é utilizado unicamente para a o
projeto de modelos lógicos de banco de dados e mais importante, que uma classe não
corresponde a uma tabela em um banco de dados.
Eventualmente uma classe pode representar o repositório lógico dos atributos de uma
tabela, no entanto, a classe não é a tabela, uma vez que os atributos de seus objetos são
armazenados em memória, ao passo que uma tabela armazena seus registros fisicamente em
disco. Além disso, uma classe possui métodos , que não existem em uma tabela. Em um modelo
lógico de banco de dados, os métodos de uma classe podem corresponder às operações que
serão realizadas sobre a tabela.
É importante destacar a existência de classes persistentes e não-persistentes, também

chamadas de transientes. Uma classe persistente é uma classe cujos objetos precisam ser
preservados fisicamente de alguma maneira, o que não ocorrem em classes transientes, cujos
objetos são destruídos durante a execução do sistema ou quando este é encerrado. Além
disso, é possível encontrar diagramas contendo tanto classes persistentes como transientes.
Nessas situações, é preciso destacar, por meio de estereótipos ou restrições, quais classes são
persistentes e quais não são.
Normalmente uma classe dita persistente em um modelo lógico terá um “correspondente” na

forma de uma tabela que preservará os atributos de seus objetos, de maneira que estes possam
ser recuperados. Isto, porém, não é uma regra; a forma como os objetos de uma classe
persistente serão preservados irá depender da forma como o software for desenvolvido. Alguns
autores recomendam o uso de uma camada de persistência,ou seja,a derivação de uma
subclasse a partir da classe cujas informações necessitam ser mantidas, em que seria definida
a maneira como as instância de cada classe seriam preservadas.
FAETEC
Relacionamentos ou Associações
As classes costumam possuir relacionamentos entre si, chamados associações, que

permitem compartilhar informações e colaborar para a execução dos processos pelo sistema.
Uma associação descreve um vínculo que ocorre normalmente entre os objetos de uma ou mais
classes.
As associações são representadas por retas ligando as classes envolvidas, podendo também
possuir setas em suas extremidades para indicar a navegabilidade da associação, o que
representa o sentido em que as informações são transmitidas entre os objetos das classes
envolvidas. As associações podem também possuir títulos para determinar o tipo de vínculo
estabelecido entre os objetos das classes, isto,é útil quando é necessária alguma forma de
estabelecimento - nesse caso é recomendável determinar também a navegabilidade da
associação para facilitar o sentido da leitura.
Associação Unária ou Reflexiva
Este tipo de associação ocorre quando existe um relacionamento de um objeto de uma

classe com objetos da mesma classe. Um exemplo de associação unária pode ser observado na
figura.
Podemos perceber nesse exemplo a existência da classe Funcionário, cujos atributos são
o código do funcionário, seu nome e o código do possível chefe do funcionário. Esse chefe
também é um funcionário, assim a associação chamada “Chefia” indica uma possível relação
entre uma ou mais instâncias da classe Funcionário com outras instâncias da mesma classe, ou
seja, tal associação determina que um funcionário possa ou não chefiar outros funcionários. Essa
associação faz que a classe possua o atributo codchefe para armazenar o código do funcionário
que é responsável pela instância do funcionário em questão. Desse modo, após consultar uma
instância da classe funcionário, pode-se utilizar o atributo codchefe da instância consultada para
pesquisar por outras instâncias da classe.
Note que existe outra informação na associação, além de seu próprio nome,
representada pelo valor “0..*” conhecida como multiplicidade. Esta procura determinar o
número mínimo e máximo de objetos envolvidos em cada extremidade da associação, além de
permitir especificar o nível de dependência de um objeto para com os outros.
FAETEC
No
caso apresentado na figura, a multiplicidade 0..* indica que um determinado funcionário pode
chefiar nenhum (0) ou muitos (*) funcionários. Pode-se perceber que só existe multiplicidade
em uma das extremidades, por default. Quando não existe multiplicidade explícita, entende-se
que a multiplicidade é “1.1”, significando que um e somente um objeto dessa extremidade da
associação se relaciona com os objetos da outra extremidade. Nesse exemplo significa que um
funcionário pode ou não chefiar outros funcionários, mas um funcionário possui um e apenas
um funcionário como chefe imediato.
Exemplos de multiplicidade
Multiplicidade Significado
0..1 No mínimo zero (nenhum) e no máximo 1. Indica que os objetos das

classes associadas não precisam obrigatoriamente estar relacionados,
mas, se houver relacionamento indica, que apenas uma instância da classe
se relaciona com as instâncias da outra classe.
1..1 Um e somente um. Indica que apenas um objeto da classe se relaciona

com os objetos de outra classe.
0..* No mínimo nenhum e no máximo muitos. Indica que pode ou não haver
instâncias da classe participando do relacionamento.
* Muitos. Indica que muitos objetos da classe estão envolvidos no

relacionamento.
1..* No mínimo 1 e no máximo muitos. Indica que há pelo menos um objeto

envolvido no relacionamento, podendo haver muitos objetos envolvidos.
3..5 No mínimo 3 e no máximo 5. Indica pelo menos três instâncias no

relacionamento e que podem ser 4 ou 5, mas não mais do que isso.
Não é realmente necessário definir o atributo código,que armazena o código de cada

funcionário e serve como uma chave primária das instâncias da classe.Como regra geral cada
classe ao ser declarada na UML, já possui um código interno implícito, não sendo necessário
declarar um atributo exclusivamente para isso.
Nem mesmo o atributo codchefe seria realmente necessário, já que associações que possuem
multiplicidade do tipo muitos (*) em qualquer de suas extremidades forçam a transmissão do
atributo-chave contido na classe da outra extremidade da associação.
FAETEC
Associação Binária
Ocorrem quando são identificados relacionamentos de objetos de duas classes.
Exemplo de associação binária.
Nesse exemplo, um objeto da classe sócio pode se relacionar ou não com a instância da
classe dependente, conforme demonstra a multiplicidade 0..* , caso exista um objeto da classe
dependente, ele terá de se relacionar com um objeto da classe sócio.
Associação Ternária ou N- ária
São associações que conectam objetos de mais de duas classes. São representados por
um losango para o qual converge todas as ligações da associação.
FAETEC
Agregação
É um tipo especial de associação em que se tenta demonstrar que as informações de um

objeto precisam ser complementadas pelas informações contidas em um ou mais objetos de
outra classe. Esse tipo de associação tenta demonstrar uma relação todo/parte entre os objetos
associados. O símbolo de agregação difere de associação por conter um losango na extremidade
da classe que contem os objetos-todo.
Neste exemplo um pedido pode tanto possuir apenas um item como vários e é muito
difícil determinar o número máximo de itens que um pedido pode ter. Mesmo que isso fosse
possível,na imensa maioria das vezes, o número máximo não seria atingido, o que faria com que
diversos atributos fossem deixados em branco, ocupando um espaço desnecessário.
Composição
É Uma variação da agregação, em que é apresentado um vínculo mais forte entre os

objetos-todo e os objetos-parte, procurando demonstrar que os objetos-parte tem de estar
associados a um único objeto-todo. O símbolo de composição se diferencia graficamente do
símbolo de agregação por utilizar um losango preenchido.
Observe que um objeto da classe edição deve relacionar-se a no mínimo seis objetos
da classe Artigo, podendo relacionar-se com até dez.
Especialização/Generalização
Esta associação identifica classes-mãe, chamadas gerais e classes filhas, chamadas

especializadas, demonstrando a ocorrência de herança e possivelmente de outros métodos
nas classes especializadas.
FAETEC
Dependência
Esse relacionamento como o próprio nome diz identifica, certo grau de dependência de
uma classe em relação a outra. Tal relacionamento de dependência é representado por uma
reta tracejada entre duas classes, contendo uma seta apontando a classe da qual a classe
posicionada na outra extremidade do relacionamento é dependente.
Classe Associativa
Classes associativas são produzidas quando ocorrem associações que possuem

multiplicidade muitos (*) em todas as suas extremidades. São importantes porque não existe
um lugar que se possam armazenar as informações produzidas pelas associações. Uma classe
associativa é representada por uma seta tracejada partindo do meio da associação e atingindo
uma classe.
FAETEC
Nesse exemplo a classe Autor pode se relacionar com muitas instâncias da classe Artigo,
e uma instância da classe Artigo pode se relacionar com muitas instâncias da classe Autor. Como
existe a multiplicidade muitos pra muitos, é preciso criar uma classe para guardar essas
informações.
Restrição
Constituem-se em informações extras que definem condições a serem validadas
durante a implementação dos métodos de uma classe, das associações entre as classes ou
mesmo de seus atributos. As restrições são representadas por textos limitados por chaves.
Estudo de caso
Iremos dar continuidade a modelagem de sistema para controle de submissão de
congresso, desta vez modelando o problema através do Diagrama de Classes.
• Existem diversos temas. Um tema pode possuir muitas submissões, mas uma submissão
refere-se a um tema único.
• Existem três tipos válidos de submissão: Artigos, minicursos ou palestras. Pode haver
FAETEC
muitas submissões de um determinado tipo, porém uma submissão deve-se referir a

um único tipo.
• Um autor (Submissor) pode realizar muitas submissões, no entanto, apesar de uma
submissão pode ser elaborada por mais de um autor,somente um deles deverá ficar
responsável pela submissão, e somente este será notificado da aceitação ou não de sua
submissão.
• Existem diversos avaliadores, responsáveis por analisar e fornecer notas para as
submissões que lhes forem atribuídas. Um avaliador pode avaliar muitas submissões e
cada submissão deve ser analisada por três avaliadores. Cada avaliação deve pontuar
os seguintes quesitos: Aderência aos temas do evento, ausência de marketing, clareza
de apresentação, originalidade e qualidade técnica.
• Cada avaliação pode conter comentários fornecidos pelo avaliador, que podem
representar possíveis alterações necessárias antes que a submissão seja disponibilizada
no congresso ou esclarecimentos do porquê da recusa da submissão.Uma avaliação
pode conter muitos comentários,mas um comentário refere-se unicamente a uma
avaliação.
• Cada um dos tipos de submissão possui atributos próprios, tendo como atributos
comuns somente o título da submissão e sua situação (se está sendo avaliada, foi
aprovada ou reprovada).Submissões do tipo artigo possuem como atributos próprios
o resumo e o abstract do artigo, além do arquivo contendo o artigo propriamente dito.
Já as submissões do tipo mini curso possuem os seguintes atributos particulares:
Justificativa, objetivo, duração, público-alvo, materiais necessários, o currículo do autor
proponente e o arquivo contendo um resumo do que será visto no mini curso. As
submissões do tipo palestra têm com atributos próprios o objetivo, o resumo e o
currículo do autor.
FAETEC
A classe Principal é a classe Submissão cujos atributos são o título da submissão e sua situação (em avaliação
aprovada ou reprovada), além dos métodos para consultar uma submissão para selecionar várias delas.
Observe que submissão é uma superclasse possuindo três subclasses chamadas Artigo, Mini curós e Palestra.
A Classe Autor contém as informações pessoais de cada autor (Submissor) que submeteu trabalhos
no congresso. O método importante desta classe é o método loguin. A multiplicidade da associação desta
classe com a classe submissão, um objeto da classe autor pode se associar a muitos objetos da classe
submissão (no mínimo um), porém um objeto da classe submissão só pode estar associado a um objeto da
classe autor (pode haver vários autores para uma submissão, mas somente um será notificado).
A classe Tema possui como atributo somente a descrição do tema e o método para consultar um
tema e selecionar vários temas. Um tema pode estar associado a nenhuma ou muitas submissões, mas uma
submissão só pode se associar a um tema.
A classe Tipo possui o atributo para conter sua descrição não sendo necessário qualquer método.
A classe Avaliador identifica os atributos pessoais de cada avaliador além do método que permite
um avaliador logar-se no sistema. A classe Comentário armazena a descrição de cada comentário de uma
avaliação, além dos métodos para registrá-lo, excluí-lo ou consultá- lo.
FAETEC

Apostila de MD2 Vers2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila de MD2 Vers2

Enviado por

Direitos autorais:

Formatos disponíveis

Governo do Estado do Rio de Janeiro

Secretaria de Estado de Ciência, Tecnologia e Inovação

A natureza dos sistemas

Diagnóstico médico; avaliação eletrônica.

Um modelo é uma simplificação da realidade.

O desenvolvimento de um software de qualidade é semelhante a este processo, pois

Sistemas de Informação: Armazenar, pesquisar, editar e mostrar informações para os

são guardados em bancos de dados relacionais ou orientados a objetos.

Para criá-lo são utilizadas ferramentas de modelagem de dados, as quais geram de

Princípios e Histórico da Modelagem

O rápido crescimento da capacidade computacional das máquinas resultou na

Atividades de Desenvolvimento de Um Software

Participantes de um processo de Desenvolvimento de Software

Gerentes de projeto - Responsável pela gerência ou coordenação das atividades

Modelagem Orientada a objetos

A Orientação a Objetos é um padrão de desenvolvimento de software baseada em

O modelo de objetos descreve a estrutura estática de um sistema, isto é, a estrutura

O modelo dinâmico descreve os aspectos de um sistema examinado as modificações

Paradigma da Orientação a Objetos

“Paradigma é um conjunto de regras que estabelecem fronteiras e descrevem como resolver

O enfoque tradicional para o desenvolvimento de sistemas é, por consequência, para a

Por exemplo, em um sistema acadêmico em que João é um aluno objeto e Carlos é um

Incidente: Curso, disciplina, aluno:

Um objeto é um elemento que podemos manipular acompanhar seu comportamento,

Pablo Barros :Cliente Nome do Objeto

Nome: “Pablo Barros”

Apostila de Modelagem de Dados I

O papel da abstração na orientação a objetos

A herança é outra forma de abstração utilizada na orientação a objetos. A herança pode

Ciclo de Vida de um Software

Ciclo de Vida Vantagens Desvantagens

 Fortemente documentado  Improdutivo quanto ao tempo

 Facilidade de percepção por  O risco do protótipo passar o

 Não exige grande  No descarte do protótipo

 Permite a resolução do  Continua dando mais ênfase a

 Manutenção da  Necessidade de um conversor

 Permite criar facilmente

Exemplo de Modelo de Sistema em espiral

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada). É uma

O objetivo dos diagramas é fornecer múltiplas do sistema a ser modelado, analisando-

Resumo dos diagramas da UML

Os conceitos usados nos diagramas da UML são chamados de modelos de elementos.

Os diagramas utilizados pela UML são compostos de 13(treze)diagramas estamos

Diagrama Caso de Uso

Este é o diagrama mais utilizado e o mais importante da UML, servindo de

Diagrama de Casos de Uso

Este diagrama procura, por meios de uma linguagem simples, demonstrar o

Os casos de usos referem-se a serviços, tarefas ou funções oferecidas pelo

As associações representam os relacionamentos entre os atores que

Este relacionamento é uma forma de associação entre casos de uso, na qual

Exemplo de um caso de uso de Generalização

Neste exemplo temos três opções de abertura de conta muito semelhantes

Exemplo de um Relacionamento de inclusão

Restrição em Associação de Extensão

Multiplicidade no diagrama de Casos de uso

A multiplicidade em uma associação entre um ator e um caso de uso basicamente

Exemplo de Multiplicidades em Associações entre Atores e Casos de Uso.

Uma fronteira de sistema identifica um classificador que contém um conjunto de casos

Documentações de Casos de Uso

A documentação de um caso de uso costuma descrever, por meio uma linguagem

Exemplo de documentação de um caso de uso.

Nome do Caso de Uso Realizar Submissão

Caso de Uso Geral