Vous êtes sur la page 1sur 6

Banco de Dados BD_03

Modelagem 02 de março de 2005

Gabriel Issa Jabra Shammas

MODELAGEM

● Relação de siglas utilizadas neste trabalho:

SI: Sistema de Informação

UML: Unified Model Language

1/6
1 MODELAGEM
A modelagem pode ser de software, sistema ou de dados.

A Modelagem de Dados (Análise de Dados) é um mecanismo formal proposto para representar


graficamente todos os dados necessários para fornecer, a uma Organização, informações que contribuam
para o seu sucesso.

O Modelo de Dados é um filtro (ou um conversor) do mundo real dos dados da Organização para o mundo
do computador.

“Para desenvolver software de qualidade duradoura, será necessário criar uma arquitetura de fundação
sólida que aceite modificações” [BOOCH, 2000, p. 3]

A modelagem:
a) “é uma parte central de todas as atividades que levam à implantação de um bom software” [BOOCH, 2000, p. 3];
b) “é uma técnica de engenharia aprovada e bem-aceita” [BOOCH, 2000, p. 6].

“Qualquer projeto será beneficiado pelo uso de algum tipo de modelagem” [BOOCH, 2000, p. 7].

Por que fazer a modelagem?


A verdade é que construímos modelos para compreender melhor o sistema que estamos desenvolvendo”
[BOOCH, 2000, p. 6]
.

“Quanto mais complexo for o sistema, maior será a probabilidade de ocorrência de erros ou de construção
de itens errados, caso não haja qualquer modelagem” [BOOCH, 2000, p. 7].

“Com a modelagem, alcançamos 4 objetivos:


a) os modelos ajudam a visualizar o sistema como ele é ou como desejamos que ele seja;
b) os modelos permitem especificar a estrutura ou o comportamento de um sistema;
c) os modelos proporcionam um guia par a construçào do sistema;
d) os modelos documentam as decisões tomadas” [BOOCH, 2000, p. 6].

“Com o auxílio da modelagem:


a) “delimitamos o problema que estamos estudando, restringindo nosso foco a um único aspecto por vez”
[BOOCH, 2000, p. 7]
;
b) “somos capazes de ampliar o intelecto humano. Um modelo escolhido de maneira adequada permitirá a
quem usa a modelagem trabalhar em níveis mais altos de abstração” [BOOCH, 2000, p. 7].

“A modelagem permite a compreensão de um sistema” [BOOCH, 2000, p. 14].

O modelo:
a) “é uma simplificação da realidade” [BOOCH, 2000, p. 6];
b) “fornece uma cópia do projeto de um sistema” [BOOCH, 2000, p. 6];
c) “pode abranger planos detalhados, assim como planos mais gerais com uma visão panorâmica do
sistema considerado” [BOOCH, 2000, p. 6].

“Um bom modelo inclui aqueles componentes que têm ampla repercussão e omite os componentes menores
que não são relevantes em determinado nível de abstração” [BOOCH, 2000, p. 6].

“Os modelos podem ser:


a) estruturais, dando ênfase à organização do sistema;
b) comportamentais, dando ênfase à dinâmica do sistema” [BOOCH, 2000, p. 6].

Construímos modelos para:

2/6
a) “comunicar a estrutura e o comportamento desejados do sistema” [BOOCH, 2000, pp. 3-4];
b) “visualizar e controlar a arquitetura do sistema” [BOOCH, 2000, p. 4];
c) compreender melhor o sistema que está sendo elaborando, muitas vezes expondo oportunidades de
simplificação e reaproveitamento [BOOCH, 2000, p. 4];
d) “gerenciar os riscos” [BOOCH, 2000, p. 4].

“Nenhum modelo é inteiramente suficiente” [BOOCH, 2000, p. 14].

“Sempre serão necessários vários modelos, conectados entre si, para tornar possível entender qualquer
aspecto, ainda que seja o sistema mais trivial” [BOOCH, 2000, p. 14].

“Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade”
[BOOCH, 2000, p. 7].

“Todos os sistemas podem ser descritos sob dferentes aspectos, com a utilização de modelos distintos, e
cada modelo será, portanto, uma abstração semanticamente específica do sistema” [BOOCH, 2000, p. 6].

“Modelos explícitos facilitam a comunicação” [BOOCH, 2000, p. 15].

A modelagem pode ser textual ou gráfica.

“O texto é uma forma maravilhosamente mínima e direta para escrever expressões e algoritmos” [BOOCH, 2000,
p. 14].

“Abstração é a característica essencial de uma entidade que a diferencia de todos os outros tipos de
entidades. Uma abstração define uma fronteira relativa à perspectiva do observador” [BOOCH, 2000, p. 449].

“Cenário é uma sequência específica de ações que ilustram o comportamento” [BOOCH, 2000, p. 449].

A experiência no uso de modelos sugere 4 princípios básicos de modelagem:


a) A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado
problema é atacado e como uma solução é definida [BOOCH, 2000, p. 8].
Ou seja, deve-se escolher bem os modelos com que se vai trabalhar.
Cada visão de mundo conduz a um tipo diferente de sistema, com custos e benefícios diversos [BOOCH, 2000,
p. 9]
.
Assim, como exemplo, construindo um sistema a partir da perspectiva de:
i) um desenvolvedor de banco de dados: tende-se a atribuir o foco a modelos de relacionamentos
entre entidades, cujo comportamento tente a privilegiar procedimentos armazenados e os
eventos que os iniciam [BOOCH, 2000, p. 8];
ii) um analista de análise estruturada: tende-se a usar modelos centrados em algoritmos, com o
respectivo fluxo de dados de um processo para outro [BOOCH, 2000, p. 9];
iii) um desenvolvedor orientado a objetos, tende-se a trabalhar com um sistema cuja arquitetura
estará centrada em várias classes e os padrões de interação que determinarão como essas classes
funcionarão em conjunto [BOOCH, 2000, p. 9].
b) “cada modelo poderá ser expresso em diferentes níveis de precisão” [BOOCH, 2000, p. 9].
Os melhores tipos de modelos serão aqueles que permitem a escolha do grau de detalhamento,
dependendo de quem esteja fazendo a visualização e por que deseja fazê-la” [BOOCH, 2000, p. 9].
c) “Os melhores modelos estão relacionados à realidade” [BOOCH, 2000, p. 9].
Será melhor utilizar modelos que tenham uma clara conexão com a realidade e, nos casos em que essa
conexào seja fraca, saber, de maneira exata, como esses modelos diferem do mundo real [BOOCH, 2000, p. 9].
Todos os modelos simplificam a realidade; o segredo será ter certeza de que sua simplificaçào não
ocultará detalhes importantes [BOOCH, 2000, p. 9].
“O tendão de Aquiles das técnicas estruturadas está no fato de não haver uma conexão básica entre o
modelo de análise e o modelo de projeto do sistema. Falhando a ponte sobre essa fenda, ao longo do
tempo aparecerá uma divergência entre o sistema concebido e o sistema construído [BOOCH, 2000, p. 10].
d) “Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado por meio de

3/6
um pequeno conjunto de modelos quase independentes” [BOOCH, 2000, p. 10].
“Quase independentes” significa modelos que possam ser criados e estudados separadamente, mas que
continuam inter-relacionados [BOOCH, 2000, p. 10].

“Cada tipo de modelo é organizado de modo diferente e cada um tem seu próprio foco.” [BOOCH, 2000, p. 11].

“(...) no caso de sistemas que utilizam muitos dados, predominarão modelos voltados para a visão estática
do projeto. Em sistemas centrados no uso de GUI, são importantes as visões estáticas e dinâmicas dos casos
de uso. Em sistemas de execução crítica em tempo real, a visão dinâmica do processo tende a ser mais
importante. (...) Em sistemas distribuídos, como aqueles encontrados em aplicações que utilizam a Web, os
modelos de implementação e de implantação são os mais importantes.” [BOOCH, 2000, p. 10].

“No caso de software, existem várias maneiras de se definir um modelo. As duas maneiras mais comuns
são provenientes da perspectiva de um algoritmo ou da perspectiva orientada a objetos.” [BOOCH, 2000, p. 11].

“A visão tradicional no desenvolvimento de software adota a perspectiva de um algoritmo. Nessa visão, o


principal bloco de construção do software é o procedimento ou a função. Essa perspectiva conduz os
desenvolvedores a voltar o seu foco de atenção para questões referentes ao controle e à decomposição de
algoritmos maiores em outros menores. (...) tendência a permitir sistemas instáveis. À medida que os
requisitos se modificam e o sistema cresce, será difícil fazer a manutenção de sistemas construídos a partir
do foco em algoritmos” [BOOCH, 2000, p. 11].

“A visão contemporânea no desenvolvimento de software adota uma perspectiva orientada a objeto. Nessa
visão, o principal bloco de construção de todos os sistemas de software é o objeto ou a classe. Explicando
de uma maneira simples, um objeto é alguma coisa geralmente estruturada a partir do vocabulário do
espaço do problema ou do espaço da solução; uma classe é a descrição de um conjunto de objetos comuns.
Todos os objetos têm uma identidade (você pode atribuir-lhes nomes ou diferenciá-los dos demais objetos
de alguma maneira), um estado (costuma haver dados a eles associados) e um comportamento (você poderá
fazer algo com o objeto ou ele poderá fazer algo com outros objetos) [BOOCH, 2000, p. 11].

“A UML é uma linguagem padrão para a elaboração da estrutura de projetos de software” [BOOCH, 2000, p. 13].

“A UML poderá ser empregada para a visualização, a especificação, a construção e a documentação de


artefatos que façam uso de sistemas complexos de software” [BOOCH, 2000, pp. 13-14].

“A UML é adequada para a modelagem de sistemas, cuja abrangência poderá incluir sistemas de
informação corporativos a serem distribuídos a aplicações baseadas em Web e até sistemas complexos
embutidos de tempo real” [BOOCH, 2000, p. 13].

O que é necessário pra compreender a UML?


Para compreender a UML é necessário o entendimento de 3 principais elementos [BOOCH, 2000, p. 13]:
a) os blocos básicos de construção da UML;
b) as regras que determinam como esses blocos de construção deverão ser combinados;
c) alguns mecanismos básicos que se aplicam a toda a linguagem;

Qual é a relação entre a UML e o processo?


A UML é independente do processo [BOOCH, 2000, p. 13].

“As linguagens fornecem um vocabulário e as regras para a combinação de palavras desse vocabulário com
a finalidade de comunicar algo” [BOOCH, 2000, p. 14].

“Contexto é um conjunto de elementos relacionados para um determinado propósito, como especificar uma
operação” [BOOCH, 2000, p. 451].

“Dependência é um relacionamento semântico entre dois itens, em que a alteração de um item (o item
independente) poderá afetar a semântica do outro item (um item dependente)” [BOOCH, 2000, p. 451].

4/6
“Escopo é o contexto que dá significado a um nome” [BOOCH, 2000, p. 453].

“Especificação é uma declaração textual da sintaxe e da semântica de um bloco de construção específico;


uma descrição declarativa do que alguma coisa é ou faz” [BOOCH, 2000, p. 451].

“Estado é uma condição ou situação durante a vida de um objeto, durante a qual ele satisfaz alguma
condição, realiza uma atividade ou aguarda algum evento” [BOOCH, 2000, p. 453].

“Evento é a especificação de uma ocorrência significativa, que tem uma localização no tempo e no espaço;
no contexto de uma máquina de estados, o evento é a ocorrência de um estímulo capaz de ativar a transição
de um estado” [BOOCH, 2000, p. 453].

“Generalização é um relacionamento de especialização/generalização, em que objetos do elemento


especializado (o filho) podem ser substituídos para objetos do elemento generalizado (o pai)” [BOOCH, 2000, p.
454].

“Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e o comportamento
de elementos mais gerais” [BOOCH, 2000, p. 454].

“Implementação é uma realização concreta do contrato declarado por uma interface; a definição de como
algo é construído ou computado” [BOOCH, 2000, p. 453].

“Integridade é como as coisas se relacionam, umas com as outras, de maneira apropriada e consistente”
[BOOCH, 2000, p. 454].

“Nível de abstração é um lugar na hierarquia de abstrações, abrangendo desde os níveis mais altos de
abstração (muito abstratos) até os mais baixos (muito concretos)” [BOOCH, 2000, p. 456].

“Refinamento é um relacionamento que representa a especificação completa de algo já especificado em um


determinado nível de detalhe” [BOOCH, 2000, p. 457].

“Relacionamento é uma conexão semântica entre elementos” [BOOCH, 2000, p. 457].

“Sistema é possivelmente decomposto em uma coleção de subsistemas, um conjunto de elementos


organizados para a realização de um propósito específico e descrito por um conjunto de modelos,
provavelmente sob diferentes pontos de vista” [BOOCH, 2000, p. 457].

“Subsistema é um agrupamento de elementos, em que alguns constituem uma especificação do


comportamento oferecido pelos outros elementos contidos nesse agrupamento” [BOOCH, 2000, p. 458].

“Thread é um fluxo leve de controle que pode ser executado concorrentemente com outras threads no
mesmo processo” [BOOCH, 2000, p. 458].

“Visão é a projeção em um modelo, vista a partir de uma determinada perspectiva ou ponto de vantagem e
omite as entidades que não são relevantes para essa visão” [BOOCH, 2000, p. 459].

5/6
2 REFERÊNCIAS BIBLIOGRÁFICAS
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Trad. Fábio Freitas. Rio
de Janeiro: Campus, 2000.

STAIR, Ralph M. Princípios de Sistemas de Informação: uma abordagem gerencial. 2ª. Ed. Rio de Janeiro:
LTC, 1998.

6/6