analise_de_software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Curso Técnico em Informática – ETEC Sergipe
1
CURSO TÉCNICO EM INFORMÁTICA
ANÁLISE E PROJETO DE SOFTWARE
Marcus Vinícius Andrade Côrtes
Walker Dantas Sampaio
ARACAJU-SE
2011
GOVERNO DO ESTADO DE SERGIPE
SECRETARIA DE ESTADO
DA EDUCAÇÃO
Curso Técnico em Informática – ETEC Sergipe
2
PROMOÇÃO
Governo de Sergipe
Marcelo Deda Chagas
Secretaria de Estado da Educação
Belivaldo Chagas Filho
Departamento de Educação
Maria Izabel Ladeira
Coordenação Estadual do E -Tec
Rivânia Andrade
Professor - Autor
Marcus Vinícius Andrade Côrtes
Silvio Fernandes Menezes Vasconcelos
Coordenador do curso
Marcus Vinicius Andrade Côrtes
Curso Técnico em Informática – ETEC Sergipe
3
Caros alunos
Bem-vindos ao Curso Técnico de Informática da Secretaria
de Educação a Distância, E-Etec Sergipe lhes oferece, contando com
a parceria do Ministério da Educação de Sergipel.
Vocês estão de parabéns por optarem pelo ensino a distância,
modalidade que está, a passos rápidos, incorporando -se à nossa
cultura. O avanço acelerado das tecnologias de informação e de
comunicação tem colocado as possibilidades de acesso ao
conhecimento à disposição de um contingente cada vez maior de
pessoas interessadas em ampliar sua formação profissional. A
velocidade com que os equipamentos na área da informática têm
evoluído e os aprimoramentos das conexões com a web tornaram o
ensino à distância uma proposta eficiente de se ensinar e de se
aprender. Muitos de vocês já navegam pela rede, utilizando -se de e-
mails, chats, blogs, pesquisa on -line e cursos dados por
videoconferência, tornando o ambiente virtual tão familiar quanto
era a sala de aula para os mais velhos.
A disciplina Análise e Projeto de Software, oferecida no
módulo I, será seu primeiro passo no aprendizado da programação de
computadores. Assim, ela é de fundamental importância para o
curso, pois é nela que vocês aprenderão os fundamentos básicos de
programação que servirão de alicerce para todas as demais
disciplinas na área de programação.
Nesta disciplina vocês aprenderão os principais conceitos de
programação, como variáveis, operadores lógicos e aritméticos,
estruturas de laço e estruturas de d ecisão e terão a oportunidade de
aplicar estes conceitos na prática criando algoritmos. Desta forma, ao
final dessa disciplina vocês estarão capacitados a criar algoritmos
completos e funcionais.
Por apresentar uma metodologia flexível, nossa proposta
favorece o ritmo de aprendizado de cada aluno. É preciso, no
entanto, ficar atento aos prazos e ao planejamento pessoal para os
estudos dos conteúdos e resolução das atividades avaliativas, para
que vocês não se sobrecarreguem nem percam o ritmo de estudo. E
lembre-se que a melhor forma de aprender lógica de programação é
praticando!
Sucesso a todos!
Curso Técnico em Informática – ETEC Sergipe
4
OBJETIVO DA DISCIPLINA
Sensibilizar e preparar os alunos para o desenvolvimento da
atividade análise de sistemas, fornecendo -lhes
conhecimentos e práticas sobre abordagens, métodos,
técnicas e ferramentas, sobretudo estruturadas, mas também
aplicações orientadas a objetos, que p ossam facilitar e
suportar esta atividade.
Curso Técnico em Informática – ETEC Sergipe
5
ÍNDICE
1. Introdução................................ ................................ ...................3
2. Análise Orientada para Objetos ................................ ..................3
3. Conceito de Modelagem da Informação ................................ .....6
4. Objetos ................................ ................................ .......................9
5. Atributos ................................ ................................ .....................13
6. Identificadores ................................ ................................ ............18
7. Domínio ................................ ................................ ......................20
8. Tabela................................ ................................ ......................... 20
9. Relacionamentos ................................ ................................ ........22
10. Subtipos e Supertipos ................................ ............................... 33
11. Projeto de Software ................................ ................................ ..37
12. Apêndice................................ ................................ ...................39
13. Exercícios ................................ ................................ .................42
14. Referências ................................ ................................ ..............44
Curso Técnico em Informática – ETEC Sergipe
6
Introdução
Por que é tão difícil construir um sistema de processamento de informação de grande porte:
conhecer exatamente o que estamos fazendo enquanto progredimos através dos vários passos
do desenvolvimento do software, e conseguir no final (em tempo e dentro do orçamento,
naturalmente) um sistema que satisfaça os requisitos e as expectativas do usuário e que seja fácil
de manter, modificar e compreender?
Com base na experiência, nós identificamos alguns problemas que parecem ser fundamentais.
Eles surgem a cada momento. Infes tam tanto os grandes quanto os pequenos projetos de
desenvolvimento. Numa revisão posterior, eles podem revelar -se como os principais valores de
fracasso do projeto. De uma maneira ou de outra, estes problemas baseiam -se todos na
informação ou na desinformação. Quantos dos problemas listados abaixo você não encontrou ou
experimentou em algum ponto do caminho?
Análise de Sistemas Orientada para Objetos
Trabalhando Fora de Sua Área de Especialização. Quando um especialista em computadores
consegue um novo cliente, assume um novo trabalho, ou é designado para um novo projeto,
geralmente enfrenta uma nova aplicação. Com freqüência, o novo trabalho é complet amente
alheio à experiência ou treinamento formal anteriores: em vez disso, ele envolve toda uma nova
área de conhecimento prático em contabilidade, comunicações, relatórios financeiros, química de
processamento, controle de trens, ou algo parecido.
O problema é que, de repente, há muito que aprender, e a aprendizagem de novas aplicações
levam tempo e esforços. Porém, de forma típica, muito pouco tempo é alocado especificamente
para a aprendizagem e não são colocados à disposição estruturas ou métodos para auxiliar no
processo de aprender.
Uma vez que os programas que constituirão o eventual sistema deverão estar baseados sobre, ou
estar compatíveis com o conhecimento especializado da aplicação, teremos de encontrar um meio
de identificar este conhecimento e incorporá-lo dentro do processo de desenvolvimento do
software.
Vocabulário Múltiplo/Esforços Interdisciplinares. Geralmente, os grandes sistemas de software
exigem a integração de distintas especializações. Gerentes financeiros, auditores, engenheiros ,
peritos em operações e outros equivalentes devem ser interpelados para participar do processo
de requerimentos e de análise. Na tentativa de se fazer isto, encontram -se áreas típicas de
conhecimento especializado parcialmente sob respostas, cada uma com vocabulários individuais
e às vezes conflitantes. (Por exemplo, um cadinho para o engenheiro de refrigeração é
Curso Técnico em Informática – ETEC Sergipe
7
caracterizado em termos de troca de calor e fluxo de água; para o engenheiro de sistemas, vácuo
é um recipiente que deve ser evacuado do ar. A me sma palavra, cadinho, está sendo usada para
duas entidades fisicamente distintas, porém estreitamente conexas. Da mesma forma, um pedido
no Departamento de Expedição é bastante diferente de um no Departamento de Vendas. O fato
de numa organização existirem estes vocabulários separados e mais importantes, suas estruturas
conceituais distintas
implícitas, deve ser levado a sério.
Por que modelagem da informação?
A questão pode ser complexa para não ser levantada por um só vocabulário através dos
processos informais normais. Em conseqüência, são exigidos verdadeiros esforços intelectuais
para investigar e resolver as possíveis divergências. Até que isto não esteja feito, qualquer
tentativa de estabelecer os requerimentos do sistema está destinada a ser dificu ltada, pois não se
pode ter certeza de qual vocabulário teria sido usado na formulação dos requerimentos.
Uma vez que com tanta freqüência cabe ao especialista de computadores resolverem estas
discrepâncias que ocorrem naturalmente e deslindar as suposiçõ es que elas escondem, deve ser
providenciado um método para se fazer isto e para se verificar se tem sido feito corretamente.
Mudanças na Informação. Acontece freqüentemente que os objetivos de um sistema de
computação. - as variáveis exatas postas à dispo sição de um operador - são submetidos a
mudanças durante o desenvolvimento ou mesmo depois da entrega do sistema. Similarmente, é
mais a norma do que a exceção que muda o conjunto de informações colocadas à disposição do
computador. Especialistas em contro le de processos estão particularmente familiarizados com a
situação em que a lista dos sensores a ser lida pelo computador se estabiliza somente depois de
o sistema ter sido instalado (no caso de se estabilizar).
Este padrão da mudança é uma realidade que deve encontrar lugar em nosso processo de
desenvolvimento do software. Precisamos distinguir entre as mudanças que não exercem efeito
substancial sobre o desenvolvimento correto do software (por exemplo, num sistema de
distribuição de energia, no caso de termos numa subestação sete ou oito disjuntores de circuito),
e aquelas que representam mudanças importantes na função (por exemplo, nos foi pedido que
computássemos e otimizássemos os custos de energia, adquirida de várias fontes externas e
usadas numa rede elétrica).
Quando se está trabalhando fora de nossa área de especialização, é difícil ter certeza quanto ao
que se conhece e o que não se conhece. É provável que isto se torne mais confuso ainda por
causa dos vocabulários conflitantes e porque o padrã o normal de mudança descrito anteriormente
pode transformar uma verdade do mês passado mima inverdade neste mês.
Curso Técnico em Informática – ETEC Sergipe
8
Análise de Sistemas Orientada para Objetos
Confusos na presença de um grande número de informações, as dúvidas grassam. Estas dúvidas
surgem particularmente nos sistemas de tempo real que controlam processos cuja natureza
básica não é completamente entendida mesmo pelos especialistas. É difícil também saber o que
se espera que você saiba; fatores culturais, às vezes, dificultam a exposição de nossa falta de
conhecimento. Isto pode impedir a formulação de perguntas que qualquer um faria, mas que nos
constrangemos em fazer.
Há, portanto a necessidade de um caminho no qual as informações coletadas possam ser
expostas de uma maneira que permita in specionar e confirmar ou recusar independentemente
cada “fato” separado nele contido.
Às vezes acontece, mesmo com sistemas que já estão em operação, que os especialistas
possuem informações errôneas sobre o funcionamento de algum aparelho. Num projeto de
substituição do sistema, consultamos três diferentes divisões de engenharia a fim de determinar
como funcionava determinado conjunto de equipamentos. Emergiram descrições diferentes e
fundamentalmente conflitantes. No final resultou que todos os especiali stas estavam errados.
Cada divisão "explicou" o equipamento de uma forma que fazia parecer exclusivo o aspecto do
equipamento sob sua responsabilidade, esquecendo os aspectos pelos quais as outras divisões
eram responsáveis.
Neste caso, é necessário um me io de se captar as informações de maneira a poder comparar
com a realidade, em vez de compara -Ias com as diversas e, possivelmente, inconsistentes
concepções da realidade dos usuários. Não Saber o que Isto Realmente Representa. Este
problema particularmente difícil surge com maior freqüência no desenvolvimento do software de
sistemas em aplicações tais como software para gestão de bancos de dados e de gráficos,
sistemas operacionais, sistemas de tempo real na administração de alarmes, processamento de
textos e de planilhas (spreadsheets) - onde o problema a ser tratado possui uma natureza
genérica ou utilitária. A intenção é a de que o software resultante possa ser usado para uma
grande variedade de aplicações de ordem maior impondo relativamente poucas rest rições ao
usuário.
A fim de ilustrar este conceito, consideremos o problema do gerenciamento de alarmes. Um
"alarme" pode ser pensado como sendo: qualquer evento que gere uma mensagem que deva ser
mostrada ao operador; ou a transição de um sinal desde o e stado "normal" ou "safe" para um
estado "anormal" ou "unsafe" (que gera uma mensagem que deve ser mostrada ao operador); ou
o fato de que um sinal está num estado anormal. Dependendo da definição escolhida, existem
diferentes normas apropriadas para 1) ex igir que o operador tome conhecimento da mensagem de
alarme, 2) permitir que o operador apague a mensagem de alarme em sua tela, 3) requerer que o
Curso Técnico em Informática – ETEC Sergipe
9
operador tome as medidas específicas a fim de apagar a mensagem de alarme e 4) relembrar ao
operador uma mensagem de alarme que lhe foi mostrada num dado momento no passado.
Nestas circunstâncias, pode ser difícil formular uma definição satisfatória, pois existe grande
quantidade de tópicos entrelaçados que devem ser resolvidos e porque não existe nenhum
motivo, a priori, para se preferir uma definição a outra. Toma -se necessário então um método por
meio do qual possamos esboçar as definições que poderiam ter estas entidades conceituais e
examinar as implicações destas definições.
De que Forma os Projetos Saem Errados
Conforme nossa experiência, uma falha no endereçamento dos problemas fundamentais,
baseados na informação, acima mencionados pode levar a uma ou a muitas conseqüências. Por
sorte, algumas delas, ou falha do processo, aparecem relativamente cedo na vi da de um projeto
quando ainda há tempo para tomar medidas corretivas. Tropeçando na Análise. Muitos projetos
de desenvolvimento de sistemas começam com uma fase de análise em que grande número de
informações é transmitido aos que desenvolvem sistemas por p arte dos especialistas em
aplicações. Contudo, depois de algum tempo, a confusão se instala devido à quantidade de
informações que o analista deve considerar e ao fato de que ele possui poucas ferramentas ou
técnicas para gerenciar aquelas informações. Dis so resulta um prolongado período de tropeções
enquanto o programa é prejudicado.
Conceito de Modelagem da Informação
É conveniente iniciar o projeto de desenvolvimento do software com a construção de um Modelo
de Informação do problema da aplicação. Depois disso, quando apropriado para o problema,
podem ser aplicados os outros passos da análise (diagramas de fluxo de dados, diagramas de
transição dos estados, trabalhos de requerimentos formais e similares). A separação da
construção do modelo das outras t arefas no desenvolvimento do software toma explícito o
trabalho de adquirir o conhecimento especializado da aplicação trazendo -o para dentro do
desenvolvimento do software;
como tal, este trabalho pode receber a importante atenção de que necessita para o sucesso.
Na posição de partida da fase de análise da aplicação, o modelo fornece um lugar onde pendurar
um grande volume de informações que anteriormente teriam inundado o analista. Além disso, a
natureza formal e sistemática do modelo atua no sentido de expor as inconsistências e as
lacunas, desta forma orientando
a averiguação. Uma vez produzido o rascunho do modelo, este
pode ser revisado pelos vários especialistas da aplicação de forma a confirmar a precisão das
informações que foram recebidas pela eq uipe de desenvolvimento do software. Neste estágio, é
comum descobrir que aconteceram vários erros de comunicação; estes erros podem ser
Curso Técnico em Informática – ETEC Sergipe
10
corrigidos rapidamente antes de se estabelecerem no armazém do desconhecimento comum do
projeto.
O modelo de informação então progride através de qualquer revisão que se faça necessária, cada
período servindo para registrar a informação que está sendo conhecida e, ao mesmo tempo,
servindo como instrumento de comunicação entre todas as disciplinas envolvidas no trabalho. Tal
sistemática é extremamente efetiva na detecção e na resolução das discrepâncias entre as várias
opiniões divergentes originariamente apresentadas aos que desenvolvem o software.
Neste ponto, os projetistas do software possuem clara compreensão do pro blema em análise, e os
ulteriores passos no ciclo de vida do desenvolvimento podem ser feitos partindo de uma base
firme.
Nós abstraímos coisas semelhantes e chamamos estas abstrações de objetos.
Na formulação destas abstrações, preferimos ignorar a maior parte das coisas do mundo. As
coisas restantes são agrupadas de acordo com os conceitos e as percepções que possuímos a
respeito do que significa ser, “semelhante”. O nosso conceito do que constit ui os critérios
apropriados para
determinar a semelhança é de que eles dependem dos objetivos que nós visamos.
Podemos representar um objeto abstraído por meio de uma tabela vazia.
CACHORRO
Nome Raça Comida Preferida Nascimento
Uma coluna de uma tabela representa uma característica ou atributo do objeto
Curso Técnico em Informática – ETEC Sergipe
11
CACHORRO
Nome Raça Comida Preferida Nascimento
Boris
Fifi
Rover
São Bernardo
Poodle
Mista
Enlatada
Desidratada
Mista
Janeiro, 81
Maio, 87
Julho, 83
A tabela pode ser preenchida a fim de representar as coisas do mundo real dentre as quais o
objeto foi abstraído. Representamos uma instância particular do objeto - uma única coisa do
mundo real por meio de uma linha da tabela. Escolhemos os atributos que reforçam a idéia de
semelhança que
tínhamos em mente quando abstraímos o objeto.
Para a prefeitura
CACHORRO COM LICENÇA
N.° da
Licença
Nome do
Cachorro
Raça Sexo
Nome do
Possuidor
Data da
Licença
POSSUIDOR DO CACHORRO
Nome Endereço
PROPRIEDADE TRIBUTÁVEL
N.º da
Propriedade
Valor
Avaliado
Impostos
pagos até
POSSUIDOR DA PROPRIEDADE
Nome do
Possuidor
Endereço
Para a Clínica Veterinária:
ANIMAL DE ESTIMAÇÃO
Nome Espécie Raça Sexo Nascimento Peso
POSSUIDOR DO ANIMAL
Nome do
Possuidor
Endereço
Total da
Conta
Curso Técnico em Informática – ETEC Sergipe
12
Existem relacionamentos entre os objetos que aparecem como atributos.
CACHORRO COM LICENÇA
N.º da
Licença
Nome do
Cachorro
Raça Sexo Nome do
Possuidor
Data da
Licença
Possuidor do Cachorro
Nome do
Possuidor
Endereço
Curso Técnico em Informática – ETEC Sergipe
13
O nome deste relacionamento é “POSSUI”, como em:
O possuidor do cachorro POSSUI cachorros.
A idéia de Modelo de Informação é a de descrever os OBJETOS, ATRIBUTOS DESTES
OBJETOS E RELACIONAMENTOS ENTRE ESSES OBJETOS.
Objetos
Um objeto é uma abstração de um conjunto de coisas do mundo real, da forma que:
- todas as coisas do mundo real do conjunto – as instâncias – tenham as mesmas características;
- todas as instâncias estejam sujeitas a, e em conformidade com as mes mas normas;
Existe uma complexidade adicional que se desenvolve quando duas espécies de "coisas"
diferentes são colocadas na mesma tabela. O ponto em questão é: existe um conjunto de normas
(lei, seguros, etc.) que se refere aos cachorros e um diferente conjunto de normas que se refere
aos carros. Cada operação deve dar conta disso, respondendo à pergunta:
“Que espécie de coisa é esta?". Além disso, se alguém, mais tarde , acrescentar a licença de
pesca na mesma tabela, todas as operações existentes seriam invalidadas e teriam de ser
redefinidas.
Identificando Objetos
A identificação dos objetos é uma tarefa bastante fácil. Começaremos por focalizar o problema em
pauta nos perguntando: “Quais são as coisas nesse problema?”. A maioria das coisas
provavelmente cairá em uma das cinco categorias a seguir:
1) Coisas Tangíveis
2) Funções
3) Incidentes
4) Interações
5) Especificações
Observe que estas categorias não são apresentadas como um sistema de classificação para
objetos, mas como um conjunto de “idéias de partida” para se achar os objetos de um novo
problema.
Curso Técnico em Informática – ETEC Sergipe
14
Coisas Tangíveis
Estes são os objetos mais fáceis de ser achados. Dado o problema apropriado ; não poderíamos
deixar escapar um objeto tal como:
Funções
Freqüentemente, se tivermos um objeto -função, teremos outros também. Isto aparece quando os
objetos-função estão sendo usados para fazer distinção entre funções diferentes desempenhadas
pelos mesmos ou por diferentes indivíduos (obviamente, suficientes); por isso, esperamos
encontrar Médico, Enfermeira, Paciente e objetos similares num modelo que descrev e a operação
de um hospital. Este conjunto de objetos poderia descrever o caso de uma enfermeira que fosse
atualmente paciente do hospital.
Incidentes
Objetos-incidentes são usados para representar uma ocorrência ou um evento: algo que acontece
num determinado período. Alguns objetos incidentes razoáveis são:
vôo
acidente
apresentação (de uma peça etc.)
evento (numa experiência de física nuclear)
falha do sistema
chamada de serviços (conserto de aparelhos)
Interações
Objetos-interações geralmente possuem uma qualidade de "transação" ou de "contrato" e
referem-se a dois ou mais outros objetos do modelo. Exemplos são:
compra (refere-se a comprador, vendedor e coisa comprada)
casamento (refere-se a um homem e uma mulher)
Os objetos-interações podem também aparecer durante a modela gem de sistemas geométricos
ou topológicos: uma rede elétrica, a tubulação de uma refinaria, ou linhas de trilhos de ferrovia.
Curso Técnico em Informática – ETEC Sergipe
15
Especificações
Objetos-especificações aparecem freqüentemente em aplicações relacionadas com estoques ou
fabricação. Por exemplo:
Refrigerador
Série ## Modelo Local atual
123961 169A Ex
123962 169A Cc
161962 172 Lo
161921 172 Ex
O "objeto-instância" não deve necessariamente representar algo tangível . Por exemplo: Podemos
ter Tipos de Apólices (o objeto-especificação) e Apólices de Seguro (as instâncias).
Atribuindo Nomes aos Objetos
Uma boa escolha dos nomes para os objetos contribuirá significativa mente para a legibilidade e a
compreensibilidade do modelo de informação . Prefira nomes que sejam claros , diretos e
verdadeiros embora isto nem sempre seja fácil .
Em geral, preferimos denominar um objeto do modelo com o mesmo nome usado para as
instâncias do objeto no mundo real . Infelizmente isto, muitas vezes, se revela difícil . A não ser que
a organização envolvida tenha passado recente mente por um processo de formalização da
terminologia, provavelmente encontraremos:
- um só nome sendo usado para referir-se a duas ou mais coisas diferentes;
- dois ou mais nomes sendo usados para referir -se à mesma coisa;
- uma variedade de circunstâncias nas quais as duas coisas acontecem simultaneamente .
Embora possa provocar muita confusão no pobre anali sta (a saber, nós), na organização cria
menor confusão do que se poderia esperar . Isto por que:
- A maior parte das referências à terminologia acontece na conversação
ordi nária, que fornece o
contexto para cada uma destas referências.
- Muitas referências à terminologia são trocadas entre especialistas da aplicação - pessoas que
possuem grandes reservas de conhecimento especializado da matéria e contexto para o tópico
em discussão.
- Os seres humanos são extremamente competentes em usar informações de contexto para
estabelecer os significados.
Curso Técnico em Informática – ETEC Sergipe
16
Porém, quando se torna necessário transferir o conhecimento da aplicação especializada para
especialistas de uma área diferente (por exemplo, especialistas em computadores) a imprecisão
da terminologia que dependa do contexto começa a causar problemas.
Nomes Precisos. Tendo nomes comuns, juntar -lhes apostos para torná-los mais
precisos.
Descrição do Objeto. Uma sala, ou área, fechada ou parte de depósito onde os itens de
estoque estão guardados.
Nome básico: Dependência
Nome preciso: Dependência de Armazenagem
Nomes Baseados na Natureza Essencial. Usar nomes reunidos, mesmo se são mais
compridos, quando eles conseguem apreender melhor o caráter essencial do objeto do
que os termos mais usuais mas menos precisos.
Descrição do Objeto: Uma parte de território, não necessariamente contíguo, delimitada
pela intersecção de todos os distritos votantes. Em função do mecanismo através do qual
um território é delimitado, todos os eleitores aí residentes recebem uma cédula idêntica
para qualquer eleição.
Nome comum: distrito (ou divisão distrital)
Melhor: Unidade Territorial Mínima
Nomes Baseados no Conteúdo. Nomear o objeto pelo conteúdo de informação, e não
pela forma comumente usada para transportar a informa ção.
Descrição do Objeto: Uma pessoa legalmente autorizada a dirigir um veículo a motor.
Ruim: Licença de Motorista
Bom: Motorista Autorizado.
(Se realmente fosse uma Licença de Motorista , a descrição seria "um pequeno pedaço de
papel, medindo 2,25 por 3,25 polegadas, contendo um nú mero de identificação”).
Atributos
Curso Técnico em Informática – ETEC Sergipe
17
Um atributo é a abstração de uma única característica possuída pe las entidades que
foram, elas também, abstraídas como um objeto.
O objetivo deve obter um conjunto de atributos que sejam:
- completos - eles abrangem todas as informações pertinentes ao objeto que está sendo
definido;
- totalmente fatorados - cada atributo capta um aspecto separado da abstração do objeto;
- mutuamente independentes - os atributos assumem seus valores ficando independentes
um do outro.
Exemplo: Vamos supor que estamos tentando caracterizar os clientes de uma companhia
que fornece um pacote de software de apoio. Esta caracterização formará o fundamento
de um banco de dados a ser utilizado pelos vários departamentos da companhia que
devem fornecer os serviços aos clientes.
Notação
Existem várias notações diferentes que podem ser usadas para mostrar um objeto
juntamente com seus atributos.
Primeiro uma tabela vazia:
CLIENTE
Nome
do Cliente
Endereço
Serviço de
Boletins
Enviar
Revisões?
Serviço de
Telefone?
Versão
Usada?
Uma forma gráfica equivalente é:
CLIENTE
Nome do cliente
Endereço
Serviço de boletins
Enviar revisões
Serviço de telefone
Versão usada
Uma forma textual equivalente:
Cliente (Nome do Cliente, Endereço, Serviço de Boletins , Enviar Revisões, Serviço de
Telefone, Versão Usada).
Todas as formas acima mostram um objeto juntamente com todos os seus atributos . Se
Curso Técnico em Informática – ETEC Sergipe
18
quisermos falar de um único atributo, uma boa forma de usar é <objeto>. <atributo> como
em:
Cliente. Endereço
Cliente. Versão Usada
e assim por diante.
Achando e Identificando Atributos
Os atributos podem ser identificados fazendo referência:
- às instâncias do mundo real que foram abstraídas para se tomar objetos: que espécies
de características possuem estas instâncias?
- à descrição do objeto: que informação precisaríamos conhecer a propósito de uma
entidade do mundo real para dizer que é urna instância deste objeto?
Os atributos que você identificar cairão dentro de três categoria s, relacionadas abaixo,
dependendo da espécie de informação captada por cada um deles:
a) Atributos descritivos - características, intrínsecas ao objeto ;
b) Atributos nominativos - nomes e rótulos arbitrários;
c) Atributos referenciais - fatos que ligam uma instância de um objeto a uma instância de
outro objeto.
Atributos Descritivos
Atributos descritivos suprem fatos intrínsecos a cada instância de
um objeto.
AVIÃO
• avião ID #
• altitude
• longitude
• latitude
• licença de piloto # (R)
• nome do avião
Curso Técnico em Informática – ETEC Sergipe
19
A altitude do avião N3172A é de 10.000 pés.
A latitude do avião N3172A é de 25,23 graus.
A longitude do avião N3172A é de 30,44 graus .
VÁLVULA
• código da válvula
• estado desejado
I
• estado atual
I
• microprocessador # (R)
O estado desejado da válvula 47B é FECHADA
O estado atual da válvula 47B é ABERTA
Curso Técnico em Informática – ETEC Sergipe
20
Atributos Nominativos
Os atributos nominativos fornecem fatos relativos aos nomes e rótulos arbitrários incluídos
em cada exemplo de um objeto . Em cada um dos seguintes exemplos o bservaremos que
podemos mudar os nomes ou os rót ulos de cada objeto sem mudar nada mais: ou seja,
podemos dar um novo número a um aeroplano, mas ele é ainda o mesmo aeroplano .
AVIÁ O
• avião ID # I
• altitu de
• longitu de
• latitu de
• licença de piloto #
(
R)
• nome do aeropla no I
O avião cujo avião ID é N 3172 A e cujo nome de aeroplano é The
Spirit of St. Louis.
VÁLVULA
Código da Válvula
Estado Desejado
Estado Atual
Microprocessador #(R)
O Código da Válvula é 47B.
EMPREGADO
Empregado ID#
Salário
Endereço
Nome do Departamento(R)
Nome do Empregado
O ID do Empregado é 3126. Seu nome é Mary Jones.
Curso Técnico em Informática – ETEC Sergipe
21
Atributos Referenciais
Os atributos referenciais captam os fatos que ligam uma instância de um objeto a uma
instância de um objeto.
AVIÃO
Avião ID # PILOTO
Altitude Licença #
Longitude (Outros Atributos)
Latitude
Licença de Piloto #(R)
Nome do Aeroplano
Está sendo
pilotado por
O aeroplano N3172A está sendo pilotado pelo piloto cujo número de licença é U77 -34.
VÁLVULA
Código da Válvula MICROPROCESSADOR
Estado Desiderado Microprocessador #
Estado Atual (Outros Atributos)
Microprocessador #(R)
É controlada
por
A válvula 47B é controlada pelo microprocessador 11.
EMPREGADO
Empregado ID# DEPARTAMENTO
Salário Nome do Departamento
Endereço (Outros Atributos)
Nome do Departamento
Nome do Empregado
É
designado
para
O empregado 3126 é designado para o Departamento de Garantia de Qualidade.
Curso Técnico em Informática – ETEC Sergipe
22
Identificadores
Um conjunto de um ou mais atributos que singularmente distingue cada exemplo de um
objeto é um identificador para aquele objeto.
Um identificador é chamado às vezes "chave candidata".
Para tornar mais compreensível a interpretação gráfica de nosso modelo , sugerimos
marcar com um asterisco os atributos que incluem um identificador, da forma que tem
sido feita, nas ilustrações que seguem.
Um identificador pode consistir em múl tiplos atributos:
EMPREGADO
* empregado ID #
 salário
 endereço
 nome do
departamento(R
 nome do empregado
A cada empregado é destinado um único empregado ID
#. Empregado. Empregado ID = # é um identificador
para o objeto Empregado.
Empregado. Nome do Empregado NÃO é um
identificador (uma vez que dois empregados podem,
com certeza, ter o mesmo nome).
AVIÃO
* avião ID #
 altitude
 longitude
 latitude
 licença piloto # (R)
 nome aeroplano
A cada avião é destinado um único número ID por uma
agência central. Avião. Avião ID é, portanto um
identificador para o objeto Avião.
Avião. Nome do Aeroplano NÃO é um identificador, pois
duas pessoas podem escolher dar o mesmo nome a
seus aeroplanos.
CARRO
*estado
*titulo #
 Licença #
 Fabricante
 Chassi #
 Ano de fabricação
 Proprietário (R)
Curso Técnico em Informática – ETEC Sergipe
23
Um objeto pode ter vários identificadores (cada um deles consistindo em um ou mais
atributos).
CARRO
* estado
* título #
licença #
fabricante
chassi #
ano de fabricação
proprietário (R)
Neste caso, devemos escolher um identificador preferencial que será indicado com
asteriscos no modelo gráfico. Na utilização da forma textual, poderemos sublinhar o
identificador preferencial:
Carro (Estado, Número do Título, Número da Licença, Fabricante,
Número do Chassi, Ano de Fabricação, Proprietário).
Descrição dos Atributos
A descrição do atributo é um breve relato informativo que descreve de que
maneira o atributo formal reflete as características de interesse do mundo real.
Esta descrição do atributo é requerida para cada atributo presente no modelo da
informação.
CARRO
 estado
 titulo #
 Licença #
*Fabricante
*Chassi #
 Ano de fabricação
 Proprietário (R)
CARRO
*estado
 titulo #
*Licença #
 Fabricante
 Chassi #
 Ano de fabricação
 Proprietário (R)
Curso Técnico em Informática – ETEC Sergipe
24
Domínios
O conjunto de valores que o atributo pode assumir constitui seu domínio.
Para cada atributo deverá ser providenciada uma definição do domínio. Podemos levar
em consideração outros pontos sobre a definição do domínio: É correto dar valores nulos
a um Atributo? Sim, se o que está sendo indicado pelo valor nulo é "ainda não sabemos"
(falta temporária de dados) ou "nenhum ". Se, porém, esta for a nossa intenção, poderá
ser melhor definir o domínio que inclua os valores "desconhecido" e "nenhum". Todavia,
se o valor nulo está tentando indicar "não aplicável", isto não só não é correto como é
sintoma de um problema mais profundo. Existe a po ssibilidade de que realmente
tenhamos dois objetos que ainda não fo ram distinguidos: por exemplo, um objeto Pessoa
com um atributo Número de Gestações.
Isto contrasta com um objeto Carro que tem como atributo o tipo de c ondicionador de ar
que está instalado nele. Se determinado carro não tem c ondicionador de ar, o valor do
atributo poderia ser definido como sendo nulo (significando Nenhum). Observe que isto é
diferente do primeiro exemplo porque o carro poderia ter instalado um condicionador de
ar; acontece que este carro em particular não o tem.
Conceito de Tabela
Existem várias definições e regras - as chamadas regras de normali zação - que são
utilizadas para definir o modelo relacional dos dados . As regras podem ser vistas sob dois
pontos de vista. O primeiro focaliza a forma dos dados no banco de dados . A partir desta
perspectiva, a regra explica como montar as tabelas de forma que haja pouca
redundância nos dados – ou melhor, que seja minimizada a quantidade de dados
requerida para armazenar o conteúdo de certas informações.
ATRIBUTO DOMÍNIO
Fonte de Energia. Polaridade
Proprietário do Carro. Endereço
Cachorro. Raça
Câmara de Frio. Temperatura
Positiva, negativa
Todo endereço de rua reconhecido pelos correios
Poodle, Afegã, Raça Mista
0-500 Kelvin
Curso Técnico em Informática – ETEC Sergipe
25
A segunda perspectiva (aquela que nos é mais natural) considera a s regras de
normalização como sendo declarações em tomo do repertório de fo rmas adotadas em
nosso modelo (por exemplo, o fato de estarmos usando tabelas), e o significado que nós
atribuímos ao fato de estarmos usando uma forma numa determinada maneira . O que
realmente estamos dizendo quando designamos um atributo a um objeto?
Tabelas Regulares
Primeira Regra: Cada instância de um objeto possui exatamente um único valor para cada
atributo. (Há um único, somente um, elemento dos dados em cada intersecção linha-
coluna.)
Esta regra proíbe a construção de "gru pos repetitivos" que se encontram em alguns
bancos de dados.
Smith Rover 100 Canine Court
RínTinTin
Sarzak
Jones Lassie 6 Dogwood Lane
Esta regra proíbe "buracos" na tabela.
A primeira regra é realmente uma definição de "tabela" ou, na terminologia do modelo
relacional, de relação (que não deve ser confundida com relacionamento sendo este
um conceito distinto). Ela oferece uma tabela com as propriedades que q ueremos:
- Cada exemplo de um objeto ocupa exatamente uma linha.
- Os exemplos que registramos numa ta bela são tão uniformes que não há
espaço em branco.
Proprietário Modelo Fabricante Licença
Brown Sedan Ford 16923A
Green Van Chevrolet 23004C
Jones Collie 29-A-101
Curso Técnico em Informática – ETEC Sergipe
26
Relacionamentos
Um relacionamento é uma abstração de um conjunto de associações que subsiste
sistematicamente entre espécies diferentes de coisas do mundo real . Durante a
construção de um modelo de informação, nós estamos interessados em identificar as
associações entre as coisas do mundo real e em refletir essas associações em nosso
modelo como relacionamentos precisamente determinados . o relacionamento é afirmado
nos termos dos objetos formais que modelam as entidades do mundo real participantes
da associação.
A maioria dos relacionamentos pode ser afirmada também em sentido "inverso":
- Proprietário de cachorro POSSUI cachorro
- Cachorro É POSSUÍDO POR proprietário de cachorro
Visualizando do ponto de vista de cada um dos objetos que dele participam,
consideramos estas duas associações como um relacionamento simples.
Para alguns relacionamentos, a asserção , em português, do relacionamento inverso é a
mesma da afirmação original.
- O Trem ESTÁ PRÓXIMO DE a Plataforma dos Passageiros.
- A Plataforma dos Passageiros ESTÁ PRÓXIMA DE o Trem.
Alguns relacionamentos envolvem somente um objeto.
- O Dançarino ESTÁ PRÓXIMO DO Dançarino.
Entre os mesmos dois objetos , pode existir uma quantidade de relacionamentos
diferentes.
A Peça ESTÁ DISPONÍVEL NO For necedor
A Peça ESTÁ SOB REQUERIMENTO NO Fornecedor .
Um objeto pode participar de uma quantidade de diferentes relacionamentos envolvendo
diferentes objetos:
O Disquete FOI FORMATADO EM a Unidade de Disco
O Disquete É POSSUÍDO por Pessoa .
O Disquete CONTÉM Arquivos.
Curso Técnico em Informática – ETEC Sergipe
27
Relacionamentos Binários
Os relacionamentos que envolvem somente dois objetos podem ser classificados em três
formas fundamentais, dependendo do número de instâncias dos objetos que participa m
de cada instância do relacionamento. Em outras pa lavras, alguns relacionamentos são...
OBJETO A
instâncias
MULTIPLICIDADE
OBJETO B
instâncias
1:1
1:M
M:M
um-a-um: O Estado TEM UM Governador
um-a-muitos: O Dono do Cachorro POSSUI Cachorros
muitos-a-muitos: Os Autores ESCREVEM Livros
Os termos "um-a-um", "um-a-muitos" e "muitos-a-muitos" são afirmações da
multiplicidade de um relacionamento. Observar que alguns autores usam o termo
cardinalidade para este onceito. (Todavia, outros a utores usam cardinalidade para
referir-se a algo completamente diferente, d e forma que nós optamos por abandonar
este termo - esta é uma palavra desgastada.)
Podemos representar graficamente estas associações mediante a u tilização de caixas
para os objetos e flechas para os relacionamentos. Notar que a cauda da flecha
sempre parte de uma só instância de um dos objet os, enquanto a cabeça da flecha
aponta para uma (cabeça simples) ou muitas (cabeça dupla) instâncias dos objetos
associados.
Curso Técnico em Informática – ETEC Sergipe
28
A fim de diminuir o número de traços na página, podem -se combinar duas flechas dos
relacionamentos.
Governa
Estado tem um Governador
É possuído por
Dono
cachorro
possui
Cachorro
É escrito por
Autor
escreve
Livro
Governa Tem um
Estado Governador
É possuído por possui
Dono
cachorro
possui
Cachorro
É escrito por escreve
Autor Livro
Curso Técnico em Informática – ETEC Sergipe
29
Relacionamento UM-A-UM
Num relacionamento um-a-um, determinada instância de um objeto do tipo A é associada
com uma, e somente uma instância de um objeto do tipo B. Além disso , cada uma das
instâncias do objeto do tipo B deve ter associado da mesma maneira uma instância do
objeto do tipo A. Esta forma de relacionamento é indicada através do símbolo (1: 1) . Em
linguagem matemática, um relacionamento um -a-um é uma relação objetiva. Isto sugere o
seguinte esboço:
a b
a b
a b
Observe que o conjunto das instâncias do objeto A é coberto completamente.pelo
mapeamento assim como o conjunto de instâncias do objeto B. Uma associação que
apresenta este padrão é:
Estado TEM UM Governador (1: 1)
 onde ESTADO é o objeto Tipo A e Governador é o objeto Tipo B.
Como poderemos reconhecer que este é um relacionamento um -a-um? Determinado
estado tem exatamente um só governador , eleito ou atuante, por um particular período
(porque é assim que determinam as leis em todos os estados); determinada pessoa pode
ser governador de somente um estado por período (novamente, devido à lei que
determina que o governador tenha sua residência no estado qu e ele governa, não
podendo residir em mais de um estado por vez).
Curso Técnico em Informática – ETEC Sergipe
30
Ilustrando um Relacionamento (1:1)
A fim de modelar um relacionamento um -a-um, tomamos um identificador.
ESTADO GOVERNADOR
Nome do estado Nome do Governador
População Data da Posse
de um objeto (normalmente
identificador preferencial)
Nome do Estado (R)
E convertemos esse identificador
em atributo ou objeto.
Chamamos este atributo de chave estrangeira, significando que este atributo é uma chave
(identificador) para uma tabela d iferente daquela em que aparece . Observe que o novo
atributo é referencial. Este fato é indicado na figura pelo (R) acrescentado ao nome do
atributo. Para modelar um relacionamento um-a-um, a chave estrangeira pode ser
colocada numa das duas tabelas. Portanto, em vez de nome do estado, poderíamos ter
convertido num atributo Estado. Nome do Governado r.
Todavia, voltando à formulação em que é usado o atributo Govern ador. Nome do Estado
temos uma nova tarefa. Uma vez definido este atribu to adicional, teremos de providenciar
uma descrição do atributo e uma declaraç ão do domínio deste novo atributo . Como o
domínio de Governador. Nome do Estado é necessariamente o mesmo de Estado. Nome
do Estado, teremos de dizer somente:
Atributo: Governador. Nome do Estado
Descrição: O estado governado por este governador .
Domínio: O mesmo de Estado. Nome do Estado.
Ao descrevermos desta forma o domínio de um atributo referencia l, nós estamos dizendo
que os únicos valores válidos para Governador. Nom e do Estado são valores que
realmente são assumidos por Estado. Nome do Estado. Valores que poderiam ser
permitidos para Estado. Nome do Estado em alguma outra situação não são permitidos
para Governador. Nome do Estado. Desta forma, para dar um exemplo, a descrição do
atributo para Estado.
Curso Técnico em Informática – ETEC Sergipe
31
Nome do Estado (um atributo nominativo), com certeza, poderia permitir a criação de
estados com nomes como Porto Rico, Kentucky, ou Orefórnia: porém, não podemos levar
em consideração um governador de Orefónia até quando um tal estado não tenha sido
criado. Em outras palavras, os domínios para os atributos referenciais são especificados
por extensão, enquanto os domínios para os atributos não re ferenciais são especificados
por intenção.
Finalmente, observamos que a definição do relaci onamento impõe certos requerimentos,
conhecidos como restrições da integridade, a fim de assegurar que os dados do sistema
sejam compatíveis com o modelo e compatíveis consigo mesmos. As restrições da
integridade que surgem do relacionamento incondicional um-a-um, expressadas nos
termos do exemplo apresentado acima, requerem que uma implementação qualquer
baseada neste modelo dê conta do seguinte:
1.Se um estado (ou governador) deve ser retirado do sistema , o governador (ou estado)
correspondente também deverá ser retirado. Estas duas alterações devem acontecer
numa só operação a fim de deixar os dados compatíveis com o modelo.
2.Se um estado (ou governador) deve ser acrescentado ao sistema, o governador (ou
estado) correspondente deverá ser acrescentado simultaneamente.
Relacionamento UM-A-MUITOS
Num relacionamento incondicional um -a-muitos, indicado pelo símbolo (1:M), um só
exemplo de um objeto tipo A é associado com um ou mais exemplos de um objeto tipo B.
Cada instância de um objeto do tipo B é associado com exatamente uma única instância
de um objeto tipo A. O esquema da associação segue o modelo abaixo:
a A
A
A
b B
B
B
c C
C
C
Curso Técnico em Informática – ETEC Sergipe
32
Vamos novamente, observar que todas as instâncias dos dois objeto s participam do
mapeamento. Por exemplo:
Departamento É EQUIPADO POR Empregados (1 :M)
O esboço correspondente com este determinado relacionamento é o q ue segue.
Novamente, observe a convenção da dupla cabeça de flecha. Ela aponta para o objeto
dos "muitos".
Está na equipe do É equipado por
Departamento Empregado
Nome do Departamento Número de Empregado
Nome do Empregado(outros atributos)
(outros atributos)
Como poderemos saber ser este um relacionamento um-a-muitos? Nossa evidência deve
provir das declarações de terminologia e de po lítica da companhia que está sendo
modelada. Neste exemplo, presumimos que estas declarações informam q ue um único
departamento tem uma equipe composta por vários empregados, que determinado
empregado é considerado como participante da equipe de um único departamento por
vez, e que cada um dos empregados deve ser designado para um departamento.
Uma vez que "muitos" é definido como "um ou mais", nossa declaração de
relacionamento cobre o caso de departamentos de uma única pessoa. Observe que o
caso de um departamento sem em pregados (zero empregados) não está coberto. Se a
organização que estamos representando no modelo considerar válido este conceito, não
poderemos usar esta forma de relacionamento para refletir a s ituação.
Mais alguns exemplos:
Dono do Cachorro POSSUI Cachorros (1 :M)
Aeroplano É MOVIDO POR Motores (1 :M)
Cliente de Seguros POSSUI Apólices (1 :M)
Subestação CONTÉM Disjuntores (1 :M)
Curso Técnico em Informática – ETEC Sergipe
33
Ilustrando um Relacionamento UM-A-MUITOS (1:M)
Vamos começar com dois objetos , Subestação e Disjuntor. A situação do mundo real é a
de que cada disjuntor está localizado numa subestação, e de que uma subestação contém
certa quantidade de disjuntores.
Abriga Está instalado em
Disjuntor Subestação
Disjuntor ID Nome da Subestação
(outros atributos) (outros atributos)
Novamente, construímos o relacionamento exato através do desenvo lvimento de um
atributo adicional apropriado. Neste caso, tomamos um identificador a partir do "objeto
dos Muitos" - o disjuntor de circuito – e construímos um novo atributo no "objeto do Um" -
a subestação. O novo atr ibuto é referencial por natureza.
Observar que o novo atributo pode ter um nome diferente do nome do atributo do qual é
feito derivar. Em geral, tentamos nomear estes atributos
referenciais (que imp lementam o
relacionamento) em função do papel por eles desempenhado no objeto em que estão
situados; daí, local do disjuntor . Agora, devemos descrever o novo atributo e seu domínio .
Atributo: Disjuntor. Local do Disjuntor.
Descrição: A subestação na qual está instalado o disjuntor de circuito .
Domínio: O mesmo que para Subestação. Nome Subestação.
A restrição da integridade imposta por este relacionamen to é parecida com aquela do
caso um-a-um: a coleta dos valores para Disjuntor. Local do Circuito deve ser a mesma
da coleta de valores para Subestação. Nome da Subestação. Ou seja , não será válido ter
uma configuração onde exista um Disjuntor localizado em uma Subestação que não
aparece na tabela da subestação ou exista uma Subestação que não contém nenhum
disjuntor, de acordo com a tabela de Disjuntor . Conseqüentemente, uma implementação
baseada neste modelo deve adotar medidas que assegurem este nível de
compatibilidade. Em particular , deverá prever os seguintes casos :
Curso Técnico em Informática – ETEC Sergipe
34
1. Não poderá ser suprimida uma subestação na tabela da Sube stação se isto deixar
ao desamparo os disjuntores da tabela do Disjuntor sem uma subestação . Se for
necessário suprimir uma subestação, na mesma operação deverão ser suprimidos
também os disjuntores nela localizados .
2. Não poderá ser suprimido um disjuntor na tabel a do Disjuntor se tal fato desprover
uma subestação de disjuntores . Isto transgrediria a definição de subestação .
3. Naturalmente, poderá ser acrescentado um novo disjuntor se este for localizado
numa subestação existente. Contudo, se ainda a subestação não e stiver presente,
deverão ser acrescentados simultaneamente a subestação e ao menos um novo
disjuntor. Da mesma forma; quando for acrescentada uma nova subestação, deve
ser acrescentado ao menos um disjuntor a fim de povoar a subestação .
Relacionamento MUITOS-A-MUITOS
Num relacionamento muitos-a-muitos, indicado pelo símbolo (M:M) , cada instância de um
objeto tipo A é associada com uma ou mais instâncias do objeto tipo B, e cada exemplo
do objeto tipo B é associado com uma ou mais instâncias do tipo A . Esquematicamente,
teremos:
A
A
A
A
A
A
B
B
B
B
B
B
C
C
C
C
C
C
Num relacionamento (incondicional) muitos -a-muitos, todas a instâncias dos dois objetos
são cobertos pelo mapeamento.
Um exemplo de um relacionamento muitos -a-muitos é:
O Romance FOI ESCRITO POR o Autor (M:M)
Curso Técnico em Informática – ETEC Sergipe
35
Na modelagem desta associação como sendo um relacionamento muitos -a-muitos, nós
refletimos a situação do mundo real , deixando a possibilidade de 1) vários romances
escritos por um só autor e 2) a possibilidade de dois ou três autores colaborando num
único romance. Eliminamos também a possibilidade de um romance que não tenha um
autor (presumivelmente, concordamos em incluir Anônimo como sendo um autor em
nosso mundo).
Observe que fizemos, neste fragmento de modelo, algo bastante que stionável:
eliminamos a possibilidade de chamar de Autor a alguém que não produziu ao menos um
romance. Para isso, existem duas explicações possíveis:
1. Qual é a definição do objeto Autor? Para determiná -Ia, teríamos de observar a
descrição do objeto, mas é possível que Autor seja definido como um escritor de
Romance (em oposição, por exemplo, a um biógrafo.
2. Qual é o domínio do problema de ste fragmento de modelo? Se ele envolver , por
exemplo, uma pequena biblioteca de empréstimos operada como linha paralela a
um salão de beleza, é provável que o modelo esteja correto: a biblioteca de
empréstimos, em função da política dos proprietários do salão de beleza, tem em
estoque somente romances.
Por outro lado, se estivermos falando de uma bib lioteca para o público em geral ou do
mundo de um vendedor de livros, e se considerarmos o autor alguém que escreveu
qualquer espécie de livro, o modelo, em sua forma atual , não é apurado. Será necessária
alguma outra forma de relacionamento para captar a as sociação existente entre romances
e autores, uma vez que pode haver autores que nunca escreveram um romance .
A discussão acima nos afastou de nossa meta original , o relacionamento básico muitos-a-
muitos. Contudo, serviu para ilustrar a importância da afirmação de que os detalhes de
qualquer modelo particular dependem da realidade que está sendo modelada.
Simplesmente é impossível avaliar a exatidão de um modelo sem compará -lo com a
realidade que ele está tentando refletir .
Apresentamos aqui mais alguns exemplos de relacioname ntos muitos-a-muitos. Como
ponto a ponderar, tente imaginar um domínio de problema no qual estes relacionamentos
muitos-a-muitos sejam válidos. O que constitui uma descrição apropriada de cada objeto?
Curso Técnico em Informática – ETEC Sergipe
36
 O Conjunto de Discos CONTÉM Composições (M:M)
 O Vôo POUSA NO Aeroporto (M:M)
 A Peça É UM COMPONENTE DA Máquina (M :M)
Ilustrando um Relacionamento MUITOS-A-MUITOS (M:M)
Agora, vamos supor que queremos modelar um relacionamento muitos-a-muitos em
que a Peça É COMPONENTE DO Aparelho.
É composto de É componente de
PEÇA APARELHO
Número da Peça Número do Modelo
Fabricante da Peça Fabricante do Aparelho
Preço
Descrição
Tipo do Aparelho
Para fazer isto, nós construímos uma tabela especial a partir dos identificadores de
cada objeto:
COMPOSIÇÃO
Número da Peça
Fabricante da
Peça
Número do
Modelo
Fabricante do
Aparelho
103
103
21
986
GE
GE
Sears
Radio Shack
176A
92AB
12345
12345
GE
Maytag
Sears
Sears
Chamamos esta tabela de tabela de correlação, porque se necessita dela para
registrar o relacionamento, ou a correlação, entre dois outros objetos presentes na
tabela.
Subtipos e Supertipos
Vamos supor que tenhamos várias classes de coisas do mundo real. As cla sses são
nitidamente distintas, nos levando a modelar cada classe como um objeto separado. Ao
mesmo tempo, as instâncias do mundo real que compõem as classes são
Curso Técnico em Informática – ETEC Sergipe
37
significativamente parecidas, tanto que gostaríamos de captar este fato no modelo. Como
fazer isso? O exemplo que vem a seguir mostra como.
Podemos começar com os objetos separados. Os objetos Subestação e Estação de
Disjuntores modelam as unidades do mun do real do sistema de distribuição de energia
elétrica para um serviço público de transporte de massa. Os atributos com a palavra
“indicação” em seus nomes refletem dados gerados por sensores que podem ser
monitorados em tempo real.
SUBESTAÇÃO ESTAÇÃO DE DISJUNTORES
Subestação ID
Indicação Local/Remota
Indicação Certo/Errado
Indicação de Falhas
Estação De Disjuntores ID
Indicação Local/Remota
Indicação do Controle de
Energia Indicação de Defeitos
Agora destacamos todos os atributos que são comuns a todos o s objetos separados - os
objetos subtipos - e utilizamos estes atributos como base para generalizar um novo
objeto, que chamamos objeto supertipo.
ESTAÇÃO DE ELETRIFICAÇÃO
Estação De Eletrificação ID
Indicação Local/Remota
Indicação do Controle de Energia
Indicação de Defeitos
Como próximo passo, voltamos ao conjunto original do s objetos a partir do qual
generalizamos o supertipo, e retiramos todos os atributos não ident ificadores que
repetiam aqueles transferidos para o supertipo.
Agora, como faremos para manifestar o relacionamento entre o nosso objeto supertipo e
os objetos subtipos a partir dos quais ele foi abstraído? Uma das maneira s já é conhecida:
ESTAÇÃO DE ELETRIFICAÇÃO
Estação De Eletrificação ID
Indicação Local/Remota
Indicação do Controle de Energia
Indicação de Defeitos
É uma
Pode ser uma
É uma
Pode ser uma
Curso Técnico em Informática – ETEC Sergipe
38
SUBESTAÇÃO
Subestação ID
Indicação de Falhas
ESTAÇÃO DE DISJUNTORES
Estação disjuntores
Indicação de Defeitos
Observe, porém que esta delineação não conta toda a estória : não informa que cada
Estação de Eletrificação deve ser ou uma Subestação ou uma Estação de Disjuntores.
Para assinalar este fato, adota-se uma convenção de desenho especial:
O relacionamento entre os objetos subtipos e seu supertipo é assinalado no desenho
como "deve ser exatamente uma das duas" ou, mais concisamente, "é uma".
Como expressaremos o relacionamento subtipo/supertipo em termos de atributos?
Basicamente, existem dois casos a ser considerados:
Se já temos os identificadores dos objetos subtipos e seus domínios são disjuntos ,
podemos criar um identificador para o objeto supertipo a partir dos identificadores de cada
um dos subtipos.
Atributo: Estação de Eletrificação ID
Domínio: idêntico à união dos domínios de Estação de Disjuntores.
Estação de Disjuntores ID e Subestação. Subestação ID.
Se os domínios dos identificadores dos subtipos não forem disjuntos, (por exemplo, se
tanto as subestações quanto as estações de disjuntores forem identificadas com a
designação de números
começados por 1), isto não serviria, pois as instâncias do supertipo (Estação de
Eletrificação) não estariam identificadas de maneira única. Aqui teremos de escolher
entre:
Criar novos identificadores arbitrários para cada um dos objetos subtipos (por exemplo ,
juntando o prefixo " S" ao identificador de uma subestação apresentado anteriormente , e
ESTAÇÃO DE ELETRIFICAÇÃO
Indicação local/remota
Indicação certo/errado do controle de energia
SUBESTAÇÃO
Subestação ID
Indicação de falhas no
transformador
ESTAÇÃO DE
DISJUNTORES
Estação disjuntores
Indicação de defeitos no
cubículo
Curso Técnico em Informática – ETEC Sergipe
39
"E" ao identificador de cada estação de disjuntores). Agora que temos desligados os
domínios dos identificadores dos subtipos, poderemos proceder como o caso 1 acima.
Criar um identificador composto para o objeto supertipo , mediante a utilização dos
identificadores não-disjuntos, já apresentados, dos subtipos juntamente com um atributo
adicional Tipo. Para este exemplo, adotamos:
Atributo: Estação de Eletrificação. Estação de Eletrificação ID
Domínio: idêntico à união dos domínios . Estação de Disjuntores.
Estação de Disjuntores ID e Subestação. Sube stação ID.
Atributo: Estação de Eletrificação. Tipo
Domínio: [subestação/estação de disjuntores]
O conceito de subtipo/supertipo pode aparecer repetidas vezes no mesmo problema ,
como apresentamos embaixo. Observe especialmente que alguns dos objetos participam
em mais de uma estrutura, de subtipo/supertipo.
Problema (Armazenagem de Peças Eletrônicas). O nosso problema consiste em
acompanhar a utilização das peças eletrônicas usadas por uma companhia especializada
em fabricar pequenos volumes de encomendas dos clientes. A companhia acomoda as
peças de acordo com o conjunto de normas apresentadas a seguir. Construa um modelo
que expresse as normas e que lhe permita responder à pergunta: "Onde posso encontrar
um 'chip' XYZ, se houver algum?".
1. Há grande quantidade de escaninhos identificáveis separadamente, cada um do
tamanho aproximado de uma caneca de café.
2. Cada escaninho contém determinado número de peças eletrônicas idênticas (por
exemplo, "chips"). Não nos interessa saber quantos "chips" há em cada escaninho.
3. Por conveniência, os escaninhos podem ser colocados sobre bandejas. Cada
bandeja foi marcada com um número de identificação vistosamente pintado nela.
4. As bandejas podem circular com facilidade, mesmo que não haja nenhum
escaninho sobre a bandeja.
5. Existem várias oficinas, cada uma contendo certo número de gabinetes.
6. As bandejas podem ser colocadas nos gabinetes.
7. Cada bandeja pode ser colocada sobre uma mesa de trabalho ou em qualquer
lugar das oficinas. As mesas de trabalho não são identificadas individualmente
(elas não possuem qualquer número ou nome e, devido ao arranjo apinhado dos
Curso Técnico em Informática – ETEC Sergipe
40
móveis, não é fácil dizer onde uma começa ou termina).
8. De tempos em tempos, damos um novo arranjo aos móveis das oficinas e, às
vezes, transportamos um gabinete de uma oficina para outra.
ASPECTOS FUNDAMENTAIS DO PROJETO DE SOF TWARE
O projeto é o primeiro passo da fase de desenvolvimento de qualquer produto ou sistema
de engenharia. Ele pode ser definido como: “... o processo de se aplicar várias técnicas e
princípios ao propósito de se dividir um dispositivo, um processo ou um sistem a com
detalhes para permitir sua realização física”. [TAY 59]
A meta do projetista é produzir um modelo ou representação de qualquer entidade que
será construída posteriormente. O processo por meio do qual o modelo é desenvolvido
combina: intuição e julgamento baseado na experiência em construir entidade
semelhante, um conjunto de princípio e/ou heurísticas que orienta a maneira pela qual o
modelo se desenvolve, um conjunto de critérios que possibilita que a qualidade seja
julgada e um processo de iteração que por fim levará a uma representação final do
projeto.
O projeto de software, como as abordagens a projetos de engenharia de outras
disciplinas, modifica-se continuamente à medida que novos métodos, uma melhor análise
e um mais amplo entendimento se des envolvem. Ao contrário do projeto de mecânica ou
de eletrônica, o projeto de software encontra -se num estágio relativamente primitivo de
sua evolução. Iniciamos uma reflexão séria da atividade de projetar software (em
oposição s “programar” ou “escrever có digos”) há pouco mais de três décadas. Portanto,
faltam à metodologia de projeto de software a profundidade, a flexibilidade e a natureza
quantitativa que normalmente se associam às disciplinas de projeto de engenharia mais
clássicas. Porém, existem técnic as, critérios de qualidade e uma notação específica que
podem ser aplicados às várias atividades do projeto de software.
PROJETO DE SOFTWARE E ENGENHARIA DE SOFTWARE
O projeto de software encontra -se no núcleo técnico do processo de engenharia de
software e é aplicado independentemente do paradigma de desenvolvimento usado.
Iniciando-se tão logo os requisitos de software tenham sido analisados e especificados, o
projeto é a primeira dentre as três atividades técnicas –projeto, codificação e teste- que
Curso Técnico em Informática – ETEC Sergipe
41
são exigidas para se construir e verificar um software. Cada atividade transforma
informações de um modo que resultará, pro fim, num software de computador validado.
Os requisitos de software, iniciados pelos modelos comportamentais, funcionais e de
informação, abastecem a fase de projeto. Usando um dentre, uma série de métodos
((discutidos em capítulos posteriores), essa fase produz um projeto de dados, um projeto
arquitetural e um projeto procedimental. O projeto de dados transforma o modelo do
domínio de informações criado durante a análise nas estruturas de dados que serão
exigidas para se implementar software . O projeto arquitetural define o relacionamento
entre os grandes componentes estruturais do programa . O projeto procedimental
transforma os componentes estruturais numa descrição do software . O código -fonte é
gerado e a atividade de teste é levada a efeito para integrar e validar o software .
As atividades de projeto, codificadas e teste absorvem 75% ou mais do custo de
engenharia de software (excluindo -se a manutenção). Nesse ponto é que tomamos
decisões que, em última análise, afetarão o sucesso da implementação do software e, o
que é igualmente importante, a facilidade com que o software
será mantido. Essas
decisões são tomadas durante o projeto, tornando -o o passo fundamental da fase de
desenvolvimento.
A importância do projeto de software pode ser estabelecida com uma única palavra -
qualidade. O projeto é o lugar onde a qualidade é fomentada durante o processo de
desenvolvimento. O projeto nos fornece representações do software que podem ser
avaliadas quanto à qualidade. É a única maneira pela qual podemos traduzir com
precisão os requisitos de um cliente num produto ou sistema de software acabado. O
projeto de software serve de base para todos os passos de engenharia e manutenção de
software que se seguirão. Sem o projeto, arriscamo -nos a construir um sistema instável -
sistema que falhará quando pequenas mudanças forem feitas, que podem ser difícil de
testar e cuja qualidade não pode ser testada até um ponto tardio do processo de
engenharia de software, quando o tempo é curto e muitos reais já foram gastos.
O PROCESSO DE PROJETO
O projeto do é o processo pelo qual os requisitos são traduzidos numa representação do
software. Inicialmente, a representação descreve uma visão holística do software.
Subseqüentes refinamentos levam a uma representação que está muito próxima ao
código-fonte.
Curso Técnico em Informática – ETEC Sergipe
42
Do ponto de vista da administração, o projeto de software é levado a efeito em dois
passos. O projeto preliminar preocupa -se com a transformação dos requisitos numa
arquitetura de dados de um software. O projeto detalhado concentra -se nos
aprimoramentos da representação estrutural que levam a representações algorítmicas e
dentro do contexto do projeto preliminar e detalhado, uma série de diferentes atividades
se desenvolve. Além dos projetos procedimentais, arquitetura e de dados, muitas
aplicações modernas têm uma atividade de projeto de interface distinta.
APÊNDICE
A análise de sistemas é uma atividade que engloba a maioria das tarefas que chamamos coletivamente de
engenharia de sistemas de computador. Freqüentemente o termo é usado no contexto de análise de
Requisitos de software. Entretanto a análise de sistemas concentra -se em todos os elementos do sistema e
não apenas no software. A análise de sistemas é realizada com os objetivos de identificar a necessidade do
usuário; avaliar a concepção do sistema quanto a sua exiquidade; executar a análise econômica e técnica;
atribuir funções ao hardware, ao software às pessoas, aos bancos de dados e aos demais elementos do
sistema; estabelecer as restrições de prazo e custos; criar uma definição do sistema que constitu a uma
base para o trabalho de engenharia subseqüente.
Tanto a perícia em hardware quanto em software é exigida para que se possa atingir com sucesso os
objetivos relacionados. O primeiro passo do processo de análise de sistema envolve a identificação da
necessidade. O analista de sistemas reúne -se com o cliente e com o usuário final. A identificação da
necessidade é o ponto de partida na evolução de um sistema baseado em computador. São objetos de
questões típicas que devem ser respondidas: a função e o desempenho desejados, questões de
confiabilidade, metas globais do sistema, requisitos de produção, mercados e concorrência, tecnologia
disponível, extensões futuras. Para começar o analista ajuda o cliente a definir as metas do sistema
(produto) com questões do tipo: Quais informações devem ser produzidas? Quai s informações devem ser
fornecidas? Que funções e desempenho são exigidos? O analista certifica -se de distinguir "necessidades"
do cliente (características que sejam cruciais para o sucesso do sistema) e "desejos"do cliente
(características desejáveis mas não essenciais).
Assim que as metas globais são identificadas o analista passa para uma avaliação das informações
complementares: Existe tecnologia para construir o sistema? Quais recursos especiais de desenvolvimento
e produção serão exigidos? Quais os l imites foram estabelecidos para os custos e para os prazos? Se o
novo sistema for de fato um produto a ser desenvolvido para a venda a muitos clientes, as seguintes
perguntas devem ser feitas: Qual o mercado em potencial para o produto? Como esse produto s e compara
com os produtos dos concorrentes? Que posição esse produto ocupa na linha de produtos global da
empresa? As informações reunidas durante a etapa de identificação das necessidades são especificadas
num Documento Conceitual do Sistema. O documento conceitual original às vezes é preparado pelo cliente
antes das reuniões com o analista. Invariavelmente a comunicação entre o cliente e o analista resulta em
modificações do documento.
Curso Técnico em Informática – ETEC Sergipe
43
O segundo passo do processo de análise que abordamos aqui é o estudo de viabilidades. O
desenvolvimento de um sistema baseado em computador é afetado pela escassez de recursos e datas de
entrega críticas. Tanto é necessário como prudente avaliar -se a viabilidade de um projeto o mais cedo
possível. Meses ou anos de esforços , milhares ou milhões de dólares e um grande embaraço profissional
podem ser evitados se um sistema mal concebido for reconhecido logo na fase de definição. A viabilidade e
a análise de riscos são relacionadas de muitas maneiras. Se o risco do projeto for grande, a viabilidade de
se produzir um software de qualidade é reduzida. Durante o trabalho de engenharia de sistema
concentramos nossa atenção em quatro áreas de interesse fundamentais: viabilidade econômica (avaliação
do custo de desenvolvimento confron tada com a renda ou benefícios últimos derivados do sistema
desenvolvido); viabilidade técnica (estudo da função, desempenho e restrições que possam afetar a
capacidade de se conseguir um sistema aceitável); viabilidade legal (determinação de qualquer infr ação,
violação ou responsabilidade legal que possa resultar do desenvolvimento do sistema); alternativas
(avaliação das abordagens alternativas ao desenvolvimento do sistema).
Um estudo de viabilidade não tem razão de ser para sistemas em que a justifica ção econômica seja óbvia,
os riscos técnicos sejam baixos, poucos problemas jurídicos sejam esperados e não exista nenhuma
alternativa razoável. Freqüentemente a viabilidade técnica é a área mais difícil de serem avaliados nesta
etapa do processo de desenvolvimento do sistema devido ao fato dos objetivos, funções e o desempenho
serem ainda um tanto vagos. É fundamental que o processo de análise e definição sejam conduzidos
paralelamente à avaliação da viabilidade técnica. Dessa forma, especificações concret as podem ser
julgadas à medida que são determinadas. Entre as considerações que normalmente são associadas à
viabilidade técnica incluem-se: riscos do desenvolvimento (O sistema pode ser projetado de forma que a
função e o desempenho necessários sejam obti dos dentro das restrições reveladas durante a análise?);
disponibilidade de recursos (Existe pessoal competente à disposição para desenvolver o sistema em
questão? Os demais recursos necessários - hardware e software - estão à disposição para a construção dos
sistemas?); tecnologia (A tecnologia progrediu para um estado que suporta o sistema?).
A viabilidade legal inclui uma ampla variedade de preocupações que inclui contratos, responsabilidade legal,
violação e uma infinidade de outras armadilhas muitas vezes desconhecidas do pessoal técnico. O estudo
de viabilidade pode ser documentado como um relatório em separado para a administração superior e
incluído como um apêndice à Especificação de Sistema. O estudo de viabilidade é revisto primeiramente
pelo gerente de projeto (para avaliar a confiabilidade do conteúdo) e pela administração superior (para
avaliar o status do projeto). O estudo deve resultar numa decisão de prosseguir/não prosseguir.
O terceiro passo é análise econômica. Trata
-se da análise custo-benefício, uma justificativa econômica para
um projeto de sistema baseado em computador. Esta análise delineia os custos para o desenvolvimento do
projeto, compara-os com os benefícios tangíveis (isto é, diretamente mensuráveis em dólares) e intangíveis
do sistema. A análise custo-benefício é dificultada por critérios que variam de acordo com as características
do sistema a ser desenvolvido, pelo tamanho relativo do projeto e pelo retorno sobre o investimento
esperado. Além disso, muitos benefícios deriva dos dos sistemas baseados em computador são intangíveis
(por exemplo, melhor qualidade de projeto mediante a otimização iterativa, maior satisfação do cliente por
Curso Técnico em Informática – ETEC Sergipe
44
meio do controle e programável e melhores decisões empresariais mediante dados de vendas prev iamente
analisados). Comparações quantitativas diretas podem ser difíceis de serem conseguidas.
O quarto passo é a análise técnica, no qual o analista avalia os méritos técnicos da concepção do sistema
e, ao mesmo tempo, coleta informações adicionais sobr e o desempenho, confiabilidade, e capacidade de
utilização. Em certos casos esta fase da análise inclui também uma quantidade limitada de pesquisa.
Questões típicas da análise técnica são, por exemplo: Quais tecnologias são exigidas para executar a
função e o desempenho do sistema? Quais materiais, métodos, algoritmos ou processos novos são exigidos
e qual o risco de desenvolvimento dos mesmos? Como essas questões tecnológicas afetarão o custo?
As ferramentas disponíveis para a análise técnica derivam das técnicas de modelagem e otimização
matemáticas tais como probabilidade e estatística, teoria das filas e teoria de controle. É importante notar,
entretanto que nem sempre uma avaliação analítica é possível. A modelagem (seja física ou matemática) é
um mecanismo efetivo para a análise técnica de sistemas baseados em computador. Um modelo é criado
tendo como base observações do mundo real ou uma aproximação baseada nas metas do sistema. O
analista analisa o comportamento do modelo e compara -o com o mundo real ou com o comportamento
esperado do sistema, conseguindo esclarecimentos sobre a viabilidade técnica do sistema proposto.
O quinto passo é a alocação e compromissos (trade -off). Assim que as questões associadas à tarefa de
análise tiverem sido respondidas , soluções alternativas serão consideradas. Cada função de sistema, com
suas características de desempenho e interface exigidas, são atribuídas a um ou mais elementos do
sistema. Por exemplo, a análise de um novo sistema gráfico de computador indica que um a função
importante é a transformação tridimensional de imagens gráficas. Uma investigação de soluções
alternativas para a função de transformação descobre as seguintes opções: todas as transformações são
executadas com o uso de software; transformações si mples são executadas em hardware enquanto
transformações complexas são executadas por software; todas as transformações são realizadas com um
processador gráfico implantado em hardware.
Cada configuração do sistema é avaliada de acordo com um conjunto de parâmetros de avaliação que são
os critérios de compromissos (trade -off), os quais são ordenados segundo sua importância. Em geral os
parâmetros de avaliação são estimados em relação a fa tores econômicos (por exemplo, custo no ciclo de
vida).
Fonte: Pressman, Roger S., 2007
Título: Engenharia de Software
Curso Técnico em Informática – ETEC Sergipe
45
EXERCÍCIOS
1) A aplicação de um conjunto interligado de técnicas formais de planejamento, análise, projeto e
construção de Sistemas de Informações em uma organização como um todo ou em um dos seus principais
setores corresponde ao conceito de:
a) Análise de Roger-Matheus.
b) Processo Pressman-Roth.
c) prototipação por heranças múltiplas.
d) engenharia de requisitos.
e) engenharia da informação.
2) Que característica NÃO é fundamental em uma linguagem de programação orientada a objeto?
a) Criação de classes.
b) Encapsulamento.
c) Herança múltipla.
d) Herança simples.
e) Instanciação de objetos.
3. Numa linguagem de programação orientada a objetos é importante restringir a visibilidade de alguns
atributos para garantir o conceito de:
a) classe.
b) Encapsulamento.
c) herança.
d) instanciação.
e) polimorfismo.
4. Para alterar o paradigma de modelagem numa organização de análise estruturada para análise orientada
a objeto, é necessário que a linguagem de programação escolhida possua suporte direto:
a) às extensões de Ward e Mellor.
b) às extensões de Hatley e Pirbhai.
c) à documentação do código.
d) à transmissão de mensagens.
e) ao backup e restore de dados.
Curso Técnico em Informática – ETEC Sergipe
46
5. Um processo administrativo numa repartição pública poderá estar nos seguintes estados: aberto, na
carga de um determinado funcionário, em trâmite ou arquivado. A ferramenta de modelagem que representa
de modo mais adequado as regras de passagem de um estado para outro é:
a) diagrama de fluxo de dados.
b) diagrama de transições de es tado.
c) diagrama entidades-relacionamentos.
d) dicionário de dados.
e) especificação de processos.
6. Qual o significado da sigla DFD?
a) Diagrama de Fluxo de Dados
b) Diagrama de Fluxo de Desenvolvimento
c) Diagrama de Formas e Desenhos
d) Disco de Formatação de Dados
e) Desenho de Fluxo de Dados
7. Marque a alternativa correta.
Qual dessas regras é utilizada para a formação de nomes nas entidades?
a) Nomes com espaço e acentuação
b) A nomeação deve ser feita de acordo com o software utilizado
c) Devem ser eliminadas preposições e conjunções
d) Os nomes devem conter mais de 32 caracteres
e) Utilizar caracteres especiais como: * % #
8. Qual dos itens abaixo não faz parte de um Modelo de Dados?
a) Representação Gráfica
b) Entidade
c) Atributo
d) Chave de Identificação
e) Classes
9. Marque a alternativa correta
A chave de identificação de uma entidade é definida por:
a) Um domínio
b) Uma ocorrência
c) Um tupla
d) um atributo, ou conjunto de atributos
e) Relacionamentos
1- e; 2-c; 3-b; 4-d; 5-b; 6-a; 7-c; 8-e; 9-d
Curso Técnico em Informática – ETEC Sergipe
47
REFERÊNCIAS
TONSING, SÉRGIO – Sérgio Luiz Tonsing, Livro: Engenharia de Software - Análise e
Projeto de Sistemas, Editora CIÊNCIA MODERNA, 2006 – São Paulo.
Autor: Sérgio Luiz Tonsig
Editora: CIENCIA MODERNA
Editora Érica: Análise e Estruturas de Sistemas de Informação
Editora Érica
Edição 1
Número de Páginas 176
Autor Nelson Peres da Silva
SISTEMAS DE INFORMAÇÃO: UM ENFOQUE GERENCIAL.
BIO, Sérgio Rodrigues.
São Paulo: Atlas, 1994. 183p.
Outras Bibliografias, WebSites e Vídeo Aulas sobre Análise
de Sistema:
http://www.mundovestibular.com.br/articles/278/1/ANALISE -
DE-SISTEMAS/Paacutegina1.html
http://guiadoestudante.abril.com.br/profissoes/ciencias -exatas-
informatica/analise-desenvolvimento-sistemas-602442.shtml
Livros
POMPILHO. Análise Essencial:Guia prático de análise de
sistemas.
YOURDON, E. Análise Estruturada Moderna.
FERNANDES. Análise de sistemas orientada ao sucesso: Por
que os projetos atrasam?
Curso Técnico em Informática – ETEC Sergipe
48
ANEXO
SOFTWARE LIVRE STARTUML
StarUML (SU) é uma ferramenta para criar diagramas de classe UML e gerar automaticamente
Java "código de stub". SU também pode fazer engenharia reversa de código -fonte Java / byte
para produzir os diagramas UML correspondente.
Neste tutorial, vamos usar SU para projetar um programa de Pizza. Execute os seguintes passos
para criar os diagramas de UML mostrado abaixo. SU irá gerar código que reflete a estrutura de
classes, mas não as ações específicas em todos os objetos. Para isso, após a criação
do
diagrama usando SU, você vai editar o código de stub resultante para adicionar o resto da
funcionalidade do código, preenchendo o que cada método deve fazer.
Figura 1
1. Instalação: Para começar, é preciso primeiro instalar o software que iremos utilizar. se não
já está instalado. O pacote, StarUML, é um software de código aberto, licenciado sob a GPL (GNU
Public License) , e está disponível gratuitamente para download a partir sua homepage . E aqui é
um link direto para o próprio pacote .
2. Uma vez StarUML ("SU") está instalado, inicie o programa.
Curso Técnico em Informática – ETEC Sergipe
49
3. Após o início do SU, uma caixa de modelo intitulado "Novo Projeto de Abordagem" podem
estar presentes: se for, selecione "Empty Project" e pressione "Ok". Sugere-se que você
desmarque a opção "Definir como abordagem padrão".
4. Sobre o "Modelo Explorer" painel no lado superior direito, selecione a (ainda) "Sem título"
do modelo.
5. Ou no menu principal em "Model", ou clicando o modelo selecionado, tem que "Ad icionar
Design"
Curso Técnico em Informática – ETEC Sergipe
50
6. Ou no menu principal em "Model", ou clicando o modelo selecionado, tem que "Adicionar
Diagrama / Diagrama de Classe":
7. Vá em "Modelo / Perfil ..." para definir o "perfil" usada pelo projeto, que determina quais os
símbolos e convenções serão em uso. Se esqueça de incluir o "Perfil Java" no projeto.
8. Salve o projeto agora para que você não perca nenhum progresso se algum problema
surge. A partir do menu "Arquivo", escolha "Salvar" e es colha um local para salvar o projeto. Seu
projeto StarUML agora deve ser algo como isto:
9. Agora para começar a realmente criar o diagrama, a partir do " Toolbox", que se inicia por
padrão no lado esquerdo da tela, selecione a opção "Class" ícone, e clicar em algum lugar na
janela do diagrama. Isso deve criar uma nova classe com um nome genérico. Renomeie a classe
para Circle clicando duas vezes sobre o nom e.
Curso Técnico em Informática – ETEC Sergipe
51
10. Adicionar um "atributo" (ou campo) para Circle clicando o objeto no diagrama, a expansão
do menu "Adicionar" e pressionar o verdes "Attribute" botão. Digite o nome do desejo do campo ",
_radius".
 Especificar o tipo de dados no painel Properties (lado in ferior direito da janela) por dupla
digitação no "tipo" slot.
 Dados internos de uma classe (campo / atributos) são sempre particulares, porque eles são
estritamente para uso pessoal pela classe para ajudar a determinar o seu comportamento. Então,
no painel de propriedades para o campo _radius, selecione PRIVATE para a sua visibilidade.
11. Repita o mesmo processo para criar uma classe chamada Retângulo com _width privado e
campos _height do tipo double. Você pode observar utilizando o "Explorer Modelo" à direit a é mais
rápida para adicionar estes, mas, no entanto, note que a adição de classes e interfaces -se nesta
caixa de ferramentas (em vez de usar a caixa de ferramentas à esquerda e clicar na paleta para
criar o objeto ) não vai criar os objetos no diagrama. Se você optar por usar o "Modelo Explorer", a
área que estarão interessados em expansão é visível após o "Modelo de Design" do grupo.
12. Criar uma interface chamada IShape
 Da caixa de ferramentas, escolha "Interface" e clique em algum lugar da paleta. Renomear o
nome genérico para IShape. Selecione a interface ao clicar com o item após sua criação.
 Na barra superior, selecione a opção "Mostrar Estereótipo" suspensa e altere o valor para
"None". Isso vai mudar a forma anterior circular em uma forma retangular .
 Também na barra de ferramentas, de -selecione a opção "Suprimir Operações" caixa. Isto irá
Curso Técnico em Informática – ETEC Sergipe
52
permitir-nos ver o que as operações da interface tem na visão diagrama.
 Adicione um método getArea do tipo duplo para a interface IShape.
 Isso pode ser feito pelo botão direito da interface, a expansão do menu de adicionar, e
pressionando o vermelho "Operação" botão. Digite o nome como: getArea.
 Para definir o tipo de retorno, expanda IShape no "Modelo Explorer", clique com o método
getArea você acabou de criar e selecione "Add Parameter". Na caixa "Propriedades", altere o
nome do parâmetro para nada ",", altere o "DirectionKind" para "RETURN" e altere o "Tipo" para o
dobro.
 Em ambos a interface do IShape si, bem como seu método getArea, marque a caixa IsAbstract
no painel de propriedades. Isso fará com que seus títulos aparecem como itálico, conforme o
padrão UML para interfaces e outras entida des puramente abstratas.
13. Faça Circle e Rectangle implementar IShape selecionando a opção "Realization" seta da
caixa de ferramentas, clicando no círculo e arrastando a linha para IShape. Repita o mesmo
processo do Rectângulo. Esta é a relação que a adição de Círculo e Retângulo irá implementar a
interface IShape.
 Para fazer a linha do conector fazer bonito dobras em ângulo reto, botão direito do mouse na
linha e selecione "Formatar / Linha / Style Rectilinear". Você pode fazer seu diagrama visual mais
limpo, basta que estabelece setas que apontam para o direito mesmo lugar em cima uns dos
outros, tornando-lhe o olhar como se houvesse apenas uma ponta de seta.
14. Como a classe Circle e Rectangle ambos implementam a i nterface IShape, eles devem ter
os mesmos comportamentos (métodos) como IShape.
 No painel Model Explorer, copiar o método getArea (Ctrl -C ou botão direito do mouse e
selecione Copiar) de IShape tanto Circle e Rectangle.
 Os métodos implementados na Circle e Rectangle aulas não são abstratas, mas concretas,
pois eles realmente executar alguma ação particular (isto é, calcular a área de um círculo e do
retângulo, respectivamente). Portanto, desmarque a caixa IsAbstract para esses métodos.
15. Seu diagrama deve agora parecido com este:
Curso Técnico em Informática – ETEC Sergipe
53
16. Adicione uma classe chamada Pizza.
 Adicionar um campo _price privada do tipo double.
 Adicionar uma operação getPrice público que retorna tipo double.
17. Para fazer referência a um IShape Pizza, Pizza seleta classe.
 Selecione a opção "DirectedAssociation" seta na caixa de ferramentas, clique em Pizza, e
arraste para IShape.
 Agora selecione a seta e em "Propriedades" caixa à direita, mud ar o nome para "has-a", a
mudança "End1.Aggregation" para "agregado" (esta é uma declaração formal de esquemas que a
pizza é feita, ou seja, "agregada", com outro objeto, um objeto de forma).
 Mude o "End2.Name" para _shape. Isto irá adicionar automaticamente um campo privado
chamado _shape de IShape tipo para Pizza.
 mudar o End2.Visibility para PRIVATE.
 Criar um "gettor" método (rotina) para getShape chamado _shape que retorna IShape. Isto é,
criar uma operação chamada getShape que retorna IShape.
18. Construtores são peças especiais de código usado para inicializar uma instância de uma
classe quando ela passa a existir.
 Para adicionar um construtor para Pizza, clique direito sobre Pizza, expanda o menu "Add" e
selecione "Operação". A partir daqui, adicionar uma operação normal, como de costume, com
preço de entrada de parâmetros de casal e forma IShape.
 Adicionando um parâmetro de entrada é apenas como a adição de um parâmetro de saída
para o tipo de retorno antes, exceto que você especifique o nome do parâmetro desejado, como
preço e forma, eo tipo de dados apropriado.
 Adicione um construtor Círculo com raio de parâmetro duplo.
 Adicione um construtor com parâmetros Rectangle largura dupla e dupla altura.
19. Seu diagrama deve agora parecido com este:
Curso Técnico em Informática – ETEC Sergipe
54
20. Para ilustrar mais um tipo de recurso UML diagrama de classes, adicionar outra classe ao
seu diagrama chamado "Test_Pizza". Esta seria uma classe que usa o Pizza
e IShape -classes
derivadas, por exemplo, para fins de teste.
 Linhas de dependência ajudar a mostrar as relações entre as classes que ocorrem de forma
mais dinâmica. Por exemplo, uma classe pode instanciar outra classe, mas não espera uma
referência permanente a ele usando um campo. Ou método de uma classe pode assumir outra
classe como parâmetro de entrada, mantendo uma referência a ele apenas para a duração da
execução desse método.
 Adicionar dependências entre as diferentes classes, selecionando a "dependência" seta da
caixa de ferramentas, selecionando uma classe dependente, e arrastando a seta para a classe
que ele é dependente. Neste exemplo, Test_Pizza "depende" Pizza, Círculo, Retângulo e porque
instancia-los.
 Digite um rótulo para uma dependência, alterando a propriedade "Name" na caixa de
Propriedades ou clicando duas vezes a linha de dependência . Normalmente, quando uma classe
instancia outra classe, que rotular a linha de dependência "instancia" (surpresa, surpresa!).
 Você pode mover o rótulo da linha de dependência em torno de um local mais estética,
selecionando o rótulo no diagrama e arrastan do-o.
 Dependências não têm efeito sobre a geração de código.
21. Seu diagrama deve agora olhar como o diagrama no topo desta página web.
22. Sinta-se livre para fazer outras modificações para o seu diagrama. Você pode arrastar os
diagramas de classe em torno e dob rar as setas de muitas maneiras diferentes (para fazer as
setas retilíneo, selecionar uma seta, clique direito, expanda formato, expanda Estilo da Linha e
selecione Rectilinear). Você apenas tem que experimentar com a ferramenta para conhecê -lo.
23. No menu Arquivo, selecione Salvar. SU usa um arquivo de projeto único para todas as
informações, assim que você deve ter apenas um arquivo gerado atualmente.
Curso Técnico em Informática – ETEC Sergipe
55
24. Será útil para exportar diagramas para outros formatos, como imagens. Você pode fazer
isso selecionando a opção "Diagrama Exportar" no menu Arquivo e escolhendo um tipo de arquivo
apropriado.
25. Para gerar o bacalhau esboço sobre Java:
 Vá em "Ferramentas" no menu principal, expanda "Java" e selecione "Generate Code".
 A partir desta caixa de diálogo, selecione o modelo, provavelmente com o nome "Model1" e
pressione "Next"
 Escolha "Selecionar Tudo" para gerar o código stub para todas as classes no seu modelo /
diagrama e em seguida, pressione "Next".
 Selecionar um diretório válido saída e selecione "Next"
 No "Setup Options", não se esqueça de verificar a "gerar a documentaçã o pelo JavaDoc" e
"Gerar JavaDoc vazio". Todas as outras caixas de seleção deve ser desmarcada. Em seguida,
pressione "Next".
 StarUML agora irá gerar os stubs código do seu diagrama. Clique em "Finish" para sair do
diálogo.
 Agora você pode editar o código stub gerado para adicionar funcionalidade ao aplicativo.
26. Agora definir o que este programa realmente faz, ou seja, escrever o código para
implementar os métodos descritos pelo seu diagrama.
 Use DrJava adicionar código para o arquivo java correspondente cla sse.. O código seria o
mesmo que você escreveu para HW02 . (Nota: o código para Test_Pizza é a melhor auto -gerada
pelo DrJava ao invés de criado por mão na StarUML Acabamos de mostrar aqui por motivos
ilustrativos..)
 Lembre-se que o getArea IShape () método é abstrato e, portanto não tem corpo de código.
 Certifique-se de adicionar comentários ao código, como mostrado no código de exemplo. Os
comentários são escritos em "JavaDoc" estilo. Você vai aprender mais sobre JavaDoc em
laboratórios subseqüentes.
27. StarUML também é capaz de criar um diagrama de classes existentes de código Java, o
que é referido como "engenharia reversa" do código. Isto é muito útil quando você tem código
Curso Técnico em Informática – ETEC Sergipe
56
existente que você deseja diagrama o u se você tiver modificado o código que foi gerado pelo
StarUML adicionando campos e métodos e, assim, deseja atualizar seus diagramas para refletir
essas mudanças. O processo de idas e vindas entre o trabalho no seu código através de um
diagrama e através de um editor de texto como DrJava, é chamado de "engenharia de ida e volta"
e é o processo de design básico usado em programação orientada a objetos.
 Fazer engenharia reversa algum código existente, vá à barra de menu principal e selecione
"Ferramentas / Java / Engenharia Reversa ...".
 Selecione o diretório que contém o Java (. Java) arquivos que você deseja usar e clique no
botão "Adicionar" ou "Add Al l" botão para incluí-los no processo de engenharia reversa.Clique em
"Next (N)".
 Selecione o modelo que você deseja adicionar as classes para, provavelmente "Model1" e
clique em "Next (N)".
 Certifique-se que as opções para a geração de "público", "pacote", "protegido" e visibilidade
"private" estão todos marcados (é o padrão).
 Além disso, por padrão, o botão "Criar campo para o atributo" deve ser selecionado.
 Menos que você queira SU para criar outra, mal dispostos de diagrama de classe, para você
mostrar todas as classes do seu modelo, desmarque a opção "Criar Diagrama da visão geral"
caixa.
 Quando você é feito verificando suas opções, clique em "Executar (R)".
 SU agora vai importar as classes nos arquivos selecionados para seu modelo. Clique em
"Finish" para sair do diálogo, quando se está completa.
 SU irá adicionar as classes importadas para o seu modelo, mas não seu diagrama. Para
adicioná-los ao seu diagrama, basta arrastá -los a partir do Model Explorer ao seu diagrama.
Aviso de erro: A partir da versão 5.0.2.1570 de StarUML, quando uma linha de generalização tem
sido excluído do esquema, ele não pode realmente ser excluído do modelo subjacente. Isto pode
causar a geração de código errônea. Para detectar se há excesso de relações ainda
remanescentes para uma classe, faça o seguinte:
1. Botão direito do mouse e selecione a classe "Editor de coleção".
2. No Editor de coleção, selecione a opção "Relações" guia.
3. A guia de Relações mostrará todas as relações associadas com a classe, tanto os da linha
apontando para fora da classe, bem como aqueles que apontam para ele.
4. Se existem relações mais mostrado na guia Relações de mostrar no diagrama, verificar para
descobrir qual deles está em erro.
5. Para excluir uma relação que não é visível no diagrama de classe, clique com o relacionamento
na guia Relações e selecione "Delete".
Material em anexo desenvolvido por http://www.cnx.org – distribuição gratuita
Fonte: http://cnx.org