Banco de Dados BD_03
Modelagem 02 de março de 2008
Gabriel Issa Jabra Shammas
MODELAGEM
Relação de siglas utilizadas neste trabalho:SI: Sistema de Informação UML: Unified Model Language
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;
Construímos modelos para:
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
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].
“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].
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.
