Engenharia de Software

Davi C. Gomes, Jordy A. S. Lima.

1. Introdução

Modelagem de sistema pode ser reconhecido como o processo de desenvolvimento

dos modelos abstratos de um sistema em que representa uma visão ou perspectiva do sistema.
Neste processo o sistema é representado através de uma notação gráfica, a qual é baseada em
notações UML (Linguagem de Modelagem Unificada), não se restringindo a isso, onde são
feitos modelos formais de um sistema, dada uma especificação detalhada. Os modelos de
sistema são usados durante o processo de engenharia de requisitos, visando o auxílio na
definição de requisitos para o sistema, sendo usados para descrever o sistema para os
engenheiros encarregados na implementação e também para documentação de utilização e
organização estrutural do sistema.
Tem-se que a característica mais importante de um modelo de sistema é que os
detalhes são descartados, uma vez que é uma abstração do sistema a ser estudado. Assim, a
abstração simplifica e seleciona as características mais importantes do sistema sem
necessariamente ter critérios para isto. Durante o desenvolvimento de modelos de sistema o
uso da notação gráfica pode ser flexível, onde os detalhes não precisam ser considerados
extremamente importantes, onde os detalhes e o nível de detalhamento do modelo depende da
pretensão de uso.

2. Modelos de contexto

Inicialmente em uma especificação de sistema, deve-se elaborar os limites do sistema,

analisando assim os stakeholders de forma a decidir quais funcionalidades devem ser
implementadas ao sistema. No que refere-se a funcionalidade deve-se focar em possíveis
sobreposições de sistemas existentes e também na decisão de onde e como uma nova
funcionalidade deverá ser adicionada, tais escolhas devem ser consideradas no estágio inicial
do processo, a fim de limitar o custo e tempo necessário nos requisitos de sistema.
Pode-se também basear-se em sistemas já implementados, assim muitas vezes evita-se
a duplicação dos dados, em contrapartida, o uso de outros sistemas pode tornar o sistema
lento limitando-o no processo de acesso às informações. Estas limitações não se restringem
apenas a esfera técnica, podendo ser gerada também através de interesses sociais e/ou
organizacionais.
Modelos de contexto demonstram que o ambiente em desenvolvimento inclui outros
sistemas automatizados, embora não mostrem os tipos de relacionamentos entre os sistemas
no ambiente e os sistema a ser especificado. Sistemas externos produzem dados ou
consomem dados do sistema especificado, compartilhando dados, conectando através de
redes ou não conectados, ou seja, não possuem barreiras mas estas relações devem ser
consideradas pois podem afetar os requisitos e o projeto do sistema.
3. Modelos de interação

Sistemas envolvem interação, de usuário, de sistema ou entre componentes do

sistema. Modelagem em interação pode ser dividida em modelagem de casos de uso, que é
usada em modelagem de interações entre sistemas e agentes externos, e diagramas de
sequência, que define interações entre os componentes do sistema podendo incluir agentes
externos.
Referindo-se a modelagem de caso de uso, tem-se que é amplamente usada em apoio
ao processo de elicitação de requisitos, onde um caso de uso pode ser considerado um cenário
simples em que descreve o que é esperado pelo cliente. Cada caso de uso é uma representação
de uma tarefa discreta em que envolve a interação externa com o sistema em que o caso de
uso é representado por elipse, com os agentes envolvidos representados por figuras-palito.
Representação por figura-palito pode representar agentes externo e hardware, mas é voltada
para representação da interação humana. Assim, define-se diagrama de caso de uso como
uma visão simples de interação, onde é necessário maior detalhamento.
Diagramas de sequência é usado para modelar interações entre agentes e objetos,
como também a interação entre os objetos do sistema, através da UML é possível o uso de
uma sintaxe rica que permite a modelagem de diversos tipos de interação. Diagramas de
sequência indica as sequências em que as interações ocorrem em um caso de uso específico
ou instância de caso de uso. A não ser que se esteja usando diagramas na geração~de código
ou documentação, não é necessária a inclusão de todas as interações aos diagramas.

4. Diagramas de classe

Diagramas de classe faz parte do desenvolvimento de um modelo de sistema

orientado a objetos a fim de exibir as classes de um sistema e as associações entre elas. Cada
associação é uma conexão que indica relacionamento entre elas. Durante o desenvolvimento
de modelos, os objetos podem, inicialmente, representar o mundo real. Os diagramas de
classe são semelhantes aos modelos semânticos de dados usado em banco de dados, em que
exibem as entidades, atributos e relações associadas.
Para gerenciamento de complexidade no sistema, generaliza-se as características mais
importantes de cada entidade, com o intuito de concluir que os diferentes membros das
classes possuem dados em comum, tendo visto isto, dentro do processo de modelagem
torna-se importante a análise para generalização das características, de forma que se torna
uma boa prática em projetos que faz com que as informações comuns sejam mantidas em um
lugar único.
Em um modelo de sistema, frequentemente é necessária a ilustração das diferentes
composições do sistema, assim a UML fornece associação entre as classes, onde define que
todo objeto é composto por outros objetos, este processo é conhecido por agregação.
5. Modelos comportamentais

Modelos comportamentais são modelos que mostram o comportamento dinâmico do

sistema ao receber um estímulo de seu ambiente. Pode pensar nesse estímulo como sendo de
dois tipos: dados e eventos.
Modelos dirigidos a dados mostram a sequência de ações envolvidas no
processamento de dados de entrada e a geração de uma saída associada. Eles são úteis pois
mostram, do início ao fim, toda a sequência de ações, desde uma entrada sendo processada
até a saída correspondente, no qual é a resposta do sistema. A UML não oferece apoio a
diagramas de fluxo de dados, pois estes foram inicialmente propostos e usados para
modelagem de processamento de dados. No entanto, devido aos sistemas dirigidos a dados
serem tão comuns no mundo dos negócios, a UML 2.0 introduziu diagramas de atividades,
semelhantes a diagramas de fluxo de dados. Uma forma alternativa de mostrar a sequência de
processamento em um sistema é o uso de diagramas de sequência da UML.
Modelagem dirigida a eventos mostra como o sistema reage a eventos externos e
internos. Ela é baseada na suposição de que um sistema tem um número finito de estados e
que os eventos podem causar uma transição de um estado para outro. A UML apoia a
modelagem baseada em eventos com diagramas e estado, baseados em ​Sratecharts (HAREL,
1987, 1988). Os diagramas de estado mostram os estados do sistema e os eventos que causam
transições de um estrado para outro. Eles não mostram o fluxo de dados dentro do sistema,
mas podem incluir informações adicionais sobre o processamentos realizados em cada estado.
O problema com a modelagem baseada em estados é que o número de possíveis estados
aumenta rapidamente. Para modelos de sistemas de grande porte, portanto, você precisa
esconder detalhes nos modelos.

6. Engenharia dirigida a modelos

A engenharia dirigida a modelos (MDE) é uma abordagem do desenvolvimento de

software segundo a qual os modelos são as saídas principais do processo de desenvolvimento
(KENT, 2002; SCHMIDR, 2006). A engenharia dirigida a modelos permite que os
engenheiros pensem em sistemas em alto nível de abstração, sem preocupação com detalhes
de implementação. Por meio de ferramentas poderosas, as implementações do sistema podem
ser geradas para diferentes plataformas a partir do mesmo modelo. Entretanto, as abstrações
apoiadas pelo modelo nem sempre são corretas para a implementação. Além disso, os
argumentos para a independência da plataforma são válidos apenas para sistemas de grande
porte e duradouros.
Arquitetura dirigida a modelos (MDA) (KLEPPE et al., 2003; MELLOR et al., 2004;
STAHL e VOELTER, 2006) é uma abordagem para projeto e implementação de software
centrada em modelos, que usa um subconjunto de modelos da UML para descrever um
sistema. O método MDA recomenda a produção de três tipos de modelos abstratos de
sistema: modelo de computação independente (CIM), Modelo de independente de plataforma
 (PIM) e modelos específicos de plataforma (PSM). Quando a MDA é introduzida, pode ser
necessário criar tradutores para fins especiais, para que sejam consideradas as características
do ambiente local. Em alguns casos pode ser impossível a tradução PIM para PSM totalmente
automatizada.
A ideia fundamental por trás da MDE é que a transformação completamente
automatizada de modelos para códigos deve ser possível. É preciso ser capaz de construir
modelos gráficos com a semântica bem-definida. Também é preciso encontrar uma maneira
de agregar informações aos modelos gráficos sobre as maneiras como as operações definidas
no modelo são implementadas. Isso é possível usando-se um subconjunto da UML 2,
chamada UML executável ou xUML (MELLOR e BALCER, 2002). Para criar um
subconjunto executável da UML, o número de tipos de modelo foi drasticamente reduzido
para três tipos de modelos-chave: modelos de domínio, modelos de classe e modelos de
estado.

7. Conclusão

Conforme foi apresentado aqui, existem vários métodos de modelagem para

representar graficamente um sistema usando UML, de maneira abstrata e ignorando alguns
detalhes. O uso do modelo irá variar dependendo do limite do sistema, da interação do
usuário, da organização do sistema e da resposta de um estímulo. Assim, conclui-se que a
construção gráfica do sistema requer um conhecimento sobre os requisitos do sistema e de
como irá funcionar além de facilitar a correção do sistema, caso for necessária.
Referências Bibliográficas

PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. 9. ed.

São Paulo: Pearson Makron Books, 2011.
HAREL, D. Statecharts: A visual formalism for complex systems. Sei. Comput.
Programming, v. 8, n. 3,1987, p. 231-274.
______ . On visual formalisms. Comm. ACM, v. 31, n. 5,1988, p. 514-530.
KENT, S. Model-driven engineering. Proc. 3rd lnt. Conf. on Integrated Formal
Methods, 2002, p. 286-298.
KLEPPE, A.; WARMER, J.; BAST, W. MDA Explained: The Model Driven
Architecture — Practice and Promise. Boston: Addison-Wesley, 2003.
MELLOR, S. J.; BALCER, M. J. Executable UML. Boston: Addison-Wesley, 2002.
MELLOR, S. J.; SCOTT, K.; WEISE, D. MDA Distilled: Principies of Model-driven
Architecture. Boston: Addison-Wesley, 2004.
SCHMIDT, D. C. Model-Driven Engineering. IEEE Computer, v. 39, n. 2,2006, p.
25-31.
STAHL, T.; VOELTER, M. Model-Driven Software Development-. Technology,
Engineering, Management. Nova York: John Wiley & Sons, 2006.