Modelagem de Sistemas – Monitoria de Engenharia de Software

Prévia do material em texto

Modelagem de Sistemas
     Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de um sistema, em que cada modelo apresenta uma visão ou perspectiva, diferente do sistema. Os modelos são usados durante o processo de engenharia de requisitos para ajudar a extrair os requisitos do sistema durante o processo de projeto, são usados para descrever o sistema para os engenheiros que o implementam; e após isso, são usados para documentar a estrutura e a operação do sistema. Pode-se desenvolver modelos do sistema existente e do sistema a ser desenvolvido.
     O aspecto mais importante de um modelo de sistema é que ele deixa de fora os detalhes. O modelo é uma abstração do sistema a ser estudado, e não uma representação alternativa dele.
     A partir de perspectivas diferentes, você pode desenvolver diversos modelos para representar o sistema. Por exemplo:
     Diagramas definidos em UML (Unified Modeling Language) (BOOCH et. Al., 2005; RUMBAUGH et al., 2004) se tornou uma linguagem de modelagem padrão para modelagem orientada a objetos. A UML apoia a criação de muitos e diferentes modelos de sistema.
     Ao desenvolver modelos de sistema, muitas vezes você pode ser flexível no uso da notação gráfica. O detalhe e o rigor de um modelo dependem de como você pretende usá-lo. Os modelos gráficos são comumente usados de três formas:
Como forma de facilitar a discussão sobre um sistema existente ou proposto;
Como forma de documentar um sistema existente;
Como uma descrição detalhada de um sistema, que pode ser usada para gerar uma implementação do sistema.
HISTÓRICO UML
     Na tecnologia da informação, a construção de modelos exige uma linguagem de modelagem que inclua elementos visuais para expressar conceitos e uma notação simples, mas poderosa para esses elementos.
     Com a crescente importância das aplicações (software) em seus negócios, muitas empresas perceberam as vantagens da orientação a objetos, e procuraram adotar técnicas que permitissem implementar o modelo orientado a objetos (OO).
     Assim, entre 1970 e 1980, muitos metodologistas desenvolveram linguagens (ou métodos) para modelar e especificar sistemas orientados a objetos, alguns influenciados por técnicas convencionais, como, por exemplo, o Modelo Entidade-Relacionamento.
     O problema é que essas linguagens se proliferaram de tal maneira que, em meados de 1994, passavam de cinquenta! Esse período ficou conhecido como “guerra dos métodos”. Os usuários não conseguiam decidir-se por uma linguagem e os fabricantes de ferramentas de modelagem sentiam-se relutantes em entrar no mercado com tantas alternativas. Assim, todos aguardavam uma solução com baixo custo não só de desenvolvimento das ferramentas, mas também de treinamento, integração e padronização dos modelos.
     A primeira versão da UML foi publicada em outubro de 1994, quando Booch e Rumbaugh, trabalhando na Rational Software Corporation, resolveram unificar seus métodos Booch e OMT que, na época, eram aceitos mundialmente.
     Um primeiro rascunho, a versão 0.8 do então denominado Método Unificado, foi lançado em Outubro de 1995, quando Jacobson trouxe seu método OOSE, agregando-o aos outros dois. Esse esforço resultou no lançamento das UML 0.9 e 0.91, respectivamente, em Junho e Outubro de 1996. Posteriormente, empresas e metodologistas contribuíram com suas ideias, resultando na UML 1.1 em 1997.
     Desde então, a responsabilidade pela evolução da UML ficou a cargo do OMG (Grupo de Gerenciamento de Objeto), seu órgão aprovador.
.
ESCOPO DA UML
     Segundo o OMG, a UML “é uma linguagem para especificação, construção, visualização e documentação de artefatos de um sistema de software intensivo”. É uma linguagem gráfica para análise, especificação e construção de sistemas para representar projetos orientados a objetos utilizando uma notação comum.
     Além de flexível, a UML é extensível e independente de processos ou linguagens de programação, o que garante a liberdade para o desenvolvedor adotar qualquer processo, metodologia ou linguagem de programação sem deixar de expressar-se claramente para os seus usuários e outros desenvolvedores, pois utiliza uma notação padrão, comum a todos os ambientes e empresas.
     A UML cobre todas as fases e processos (concepção, especificação, construção e entrega da solução) usando sempre o mesmo conjunto de diagramas, que suportam conceitos de alto nível (estrutura, padrões e componentes). A UML não fornece suporte semântico e visual que substitua uma linguagem de programação, ou seja, ela não está orientada a nenhum código e não é uma linguagem de programação. Sua notação e semântica sólidas permitem e estimulam a construção de ferramentas com interface, armazenamento, interoperabilidade e outras características que atendam às necessidades dos usuários da UML.
     A UML também não é uma metodologia ou processo, mas para empregá-la de modo eficiente e produtivo, é preciso utilizar tanto uma boa ferramenta como uma metodologia.
     Embora a UML não seja uma metodologia, a construção de modelos segue alguns passos não necessariamente impostos por ela, mas de maneira intuitiva e natural, qual seja, conhecer o problema, e desenhar, construir e implantar a solução.
     Na UML, os sistemas são constituídos por modelos que representam diferentes pontos de vista, cada um descrevendo um aspecto particular da mesma solução. Esses pontos de vista são denominados visões. Cada uma dessas visões utiliza uma notação e um conjunto de elementos apropriados para sua compreensão.
     A UML representa o sistema em cinco visões:
     As cinco visões da UML podem ser vistas como abstrações dos modelos. Cada visão dá importância a determinado aspecto do sistema, deixando os demais de lado. Elas permitem simplificar a modelagem e o desenho do sistema para melhor gerenciamento e manutenção dos modelos, assegurando, assim, maior qualidade ao produto final.
.
VISÕES DE CASO DE USO
     A visão de caso de uso serve como um contrato entre o cliente e o desenvolvedor porque mostra conceitualmente um conjunto de funções que o sistema deve executar para atender aos requisitos. O sistema é visto sob a perspectiva do usuário, por isso a visão de caso de uso ocupa uma posição central, pois serve de base para o desenvolvimento das demais visões e é essencial para atividades como análise, desenho, implementação, teste do sistema e planejamento dos trabalhos. Há somente uma visão de caso de uso no sistema.
     A modelagem de casos de uso não se limita ao desenho de elementos em um diagrama, mas também à definição do fluxo de eventos, que define o que o sistema faz e não como ele é desenhado para executar o comportamento esperado, ou seja, o fluxo de eventos não descreve nenhum detalhe de interface de usuário.
     Para saber melhores detalhes sobre cenários de caso de uso, condições, requisitos, fluxos, notações utilizadas e etc. verificar o treinamento exclusivo sobre “Casos de Uso”. Pois o foco deste treinamento é descrever todos os diagramas da notação UML, concentrando esforços em explicar mais a parte gráfica de cada um.
     Nas atividades de análise, desenho e teste, os desenvolvedores (arquitetos, desenhistas e gerentes) usam o modelo de caso de uso para especificar aspectos de arquitetura funcional, planejamento de atividades de desenvolvimento, lançamento de versões, planos de integração e teste, documentação e etc.
     Enfim, o modelo de caso de uso é um instrumento extremamente importante em todas as fases do ciclo de desenvolvimento.
.
VISÃO LÓGICA
     Visão lógica, ou estática, é um ponto de vista arquitetônico que permite estruturar e organizar o desenho do sistema de forma lógica. Ela especifica classes, subsistemas e pacotes lógicos do sistema. Apesar de ainda contar com a participação do cliente, eventualmente pelo emprego de diagramas de objetos, essa visão traduz o ponto de vista dos analistas, projetistas, desenvolvedores do sistema e quaisquer outros interessados.
     Apreocupação da visão lógica, ou estática, é descrever a funcionalidade proporcionada pelo sistema para atender os requisitos de usuário constantes na visão de caso de uso. Para isso é necessário estruturar e organizar o desenho de forma lógica, especificando as classes, subsistemas e pacotes lógicos do sistema e as colaborações dinâmicas entre os objetos.
     O diagrama de classes representam a estrutura estática do modelo, um resumo do modelo de desenho, que servirá de base para a arquitetura do sistema, garantindo toda a funcionalidade esperada pelo usuário.
     O problema é como identificar os objetos e classes do sistema. Antes da UML, a identificação de objetos era feita por meio de diversas técnicas, entre as quais podemos citar a utilização de nomes, diagrama de fluxo de dados, cartões CRC, identificação por categorias e etc. A técnica que seguiremos será baseada na Análise de Caso de Uso, proposta pelo RUP.
.
VISÃO DO PROCESSO
     A visão do processo permite entender a organização dos processos do sistema. Ela é desenvolvida a partir das visões anteriores e permite capturar os aspectos estáticos e dinâmicos em diagramas de interação, de atividade e de estado. Ela é desenvolvida na perspectiva do analista e do desenvolvedor, mas também conta com a colaboração do usuário para validação, principalmente, pelos diagramas de sequência.
.
VISÃO DE IMPLEMENTAÇÃO
     A visão de implementação captura as decisões de arquitetura para implementação do sistema, especificando os subsistemas e suas dependências e seus componentes organizados em camadas e hierarquias. Em um projeto, ela permite definir e distribuir os trabalhos de implementação, calcular a quantidade de código a ser desenvolvida  ou reutilizada e também especificar marcos de entrega dos módulos do sistema, se for o caso. Por sua natureza, essa visão é exclusiva dos analistas, desenvolvedores e integradores do projeto.
.
VISÃO DE IMPLANTAÇÃO
     A visão de implantação refere-se à distribuição física do sistema através do conjunto de nós do ambiente em que ele vai ser executado, incluindo distribuição física de processos e threads.
.
DIAGRAMAS E ELEMENTOS DA UML
Cada visão de UML é constituída de um ou mais modelos, ou seja, representações em pequena escala de um sistema sob um ponto de vista particular. Um modelo é formado por um conjunto de diagramas que apresenta diferentes versões, em diferentes níveis de detalhamento, de acordo com a parte interessada ou envolvida no sistema.
     Dependendo do porte do sistema, nem todos os diagramas são desenhados, mas qualquer projeto possui, pelo menos, diagramas de caso de uso, de interação e de classe.
     A UML possui quinze diagramas, divididos em dois grupos:
Diagramas estruturais, que descrevem os elementos estruturais que compõem o sistema, representando suas partes e seus relacionamentos;
Diagramas de comportamento, ou dinâmicos, que descrevem o comportamento dos elementos e suas interações.
 
Todo diagrama é constituído de elementos, cada um com um propósito, regras e notação diferentes para definir uma situação do processo de desenho. Embora a maioria dos diagramas seja gráfica, apresentando nós relacionados entre si por uma linha, demonstrando uma conexão, o relacionamento pode ser expresso na forma de recipiente em que um símbolo está contido em outro, ou de anexo, em que um símbolo aparece próximo a outro.
     Vale ressaltar que na UML um modelo não se resume apenas a um diagrama, pois ele é apenas uma representação visual. Além dos gráficos, há especificações escritas para os elementos.
     A especificação UML lista três tipos de relacionamentos visuais em diagramas:
Conexões: linhas que conectam ícones e símbolos, formando caminhos sempre ligados aos símbolos nas suas duas extremidades;
Recipientes: caixas, círculos e outras figuras contendo outros símbolos e linhas;
Anexos: elementos que estão visualmente agrupados e podem sugerir um relacionamento devido à proximidade.
 
Referências Bibliográficas:
Guedes, Gilleanes T. A.;2011.UML 2 : uma abordagem prática. 2nd ed. São Paulo: Novatec Editora.
Sommerville, Ian. Engenharia de Software - 9. ed. São Paulo, 2011.
Booch, G.; Rumbaugh, J.; Jacobson, I.; 2005. The Unified Modeling Language User Guide. 2nd ed. Addison-Wesley Professional.
Fowler, M.; Scott, K.;1999. UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language.2nd ed.
We reserve the rights for some potential vector used in any post to http://all-free-download.com/free-vector/ and http://www.freepik.com/ and their respective authors.