INF1404 – MODELAGEM DE SISTEMAS - inf.puc-rio.brivan/PROMINP/NotasAula/MS-CAP-01.pdf ·...

INF1404 – MODELAGEM DE SISTEMAS

Bacharelado em Sistemas de Informação

Ivan Mathias Filho

[email protected]

© LES/PUC-Rio

Programa – Capítulo 1

• Princípios de Modelagem

• O Paradigma Funcional

• O Paradigma Orientado a Objetos

© LES/PUC-Rio





© LES/PUC-Rio

A Importância da Modelagem (1)

Sistemas de pouca complexidade podem ser construídos sem um planejamento prévio.

© LES/PUC-Rio

A Importância da Modelagem (2)

Sistemas complexos exigem planejamento rigoroso e trabalho em equipe.

© LES/PUC-Rio

O Que é um Modelo?

“Um modelo é uma simplificação da realidade”.

© LES/PUC-Rio

Por Que Construímos Modelos?

• O ser humano é limitado em relação à sua capacidade de compreender sistemas complexos;

• Devemos dividir grandes problemas em problemas menores – dividir para conquistar;

• A modelagem nos ajuda na tarefa de compreender sistemas grandes e complexos.

“Construímos modelos de sistemas complexos porque não é possível compreendê-los na sua

totalidade”.

© LES/PUC-Rio

Controle da Complexidade

© LES/PUC-Rio

Controle da Complexidade

© LES/PUC-Rio

Objetivos da Modelagem (1)

• Visualizar um sistema como ele é ou como desejamos que ele seja;

• Especificar a estrutura ou o comportamento de um sistema;

• Criar especificações que sirvam de guias para a construção de um sistema;

• Documentar as decisões tomadas em relação a um sistema.

© LES/PUC-Rio

Objetivos da Modelagem (2)

“O Objetivo da Engenharia de Software não éconstruir modelos e documentos, mas desenvolver sistemas que satisfaçam as necessidades dos clientes”.

© LES/PUC-Rio

Múltiplas Visões (1)

“Projetos complexos demandam modelos com diferentes níveis de precisão”.

© LES/PUC-Rio

Múltiplas Visões (2)

“Visões distintas e quase independentes de um sistema complexo nos ajudam na sua

investigação”.

© LES/PUC-Rio





© LES/PUC-Rio

Dimensões do Software

• Qualquer discussão sobre a busca de uma arquitetura adequada a um sistema de software deve levar em conta os seguintes aspectos:

© LES/PUC-Rio

O Problema da Decomposição

• Se nos abstrairmos da existência de múltiplos processadores – reais ou virtuais – a questão passa a ser a seguinte:

© LES/PUC-Rio

Decomposição Funcional (1)

• A decomposição funcional clássica de um sistema baseia-se em refinamentos sucessivos, começando com a definição da sua função principal:

[F0] Emite Contracheque dos Funcionários

• Cada etapa seguinte deve diminuir o nível de abstração dos elementos obtidos:

[F1] Leia os dados dos funcionários[F2] Leia os registros de ponto dos funcionários[F3] Calcule os salários brutos em função das horas trabalhadas[F4] Calcule os impostos a serem deduzidos[F5] Emita os contracheques dos funcionários

© LES/PUC-Rio

Decomposição Funcional (2)

• Se optarmos por um pseudo-linguagem de programação, a decomposição anterior assumiria a seguinte forma:

inícioinicialize acumuladores e abra arquivos;leia arquivo de funcionários;enquanto houver funcionários faça:

leia ponto do funcionário;enquanto houver registro de ponto do funcionário faça:

acumule horas trabalhadas;leia ponto do funcionário;

fim-enquantocalcule salário bruto;calcule impostos e salário líquido;imprima contracheque;leia arquivo de funcionários;

fim-enquantoimprima relatório com os totais de pagamento;feche os arquivos;

fim

© LES/PUC-Rio

Desvantagens da Decomposição Funcional

• Uma das desvantagens da decomposição funcional por refinamentos sucessivos é a ênfase prematura nas restrições temporais;

• Cada refinamento expande uma parte da estrutura abstrata em uma seqüência de operações com estruturas de controle detalhadas;

• Tais restrições de controle passam a ser essenciais àarquitetura obtida, embora elas estejam sujeitas àmudanças;

• Isso diminui a flexibilidade da arquitetura em relação àacomodação de futuras alterações nos requisitos do sistema.

© LES/PUC-Rio

Uso de DFDs

• Algumas das deficiências decorrentes da amarração prematura das estruturas de controle podem ser corrigidas com o uso de Diagramas de Fluxos de Dados (DFDs):

© LES/PUC-Rio

Vantagens da Decomposição Funcional

• A decomposição funcional por refinamentos sucessivos possui várias características positivas:

– É uma disciplina logicamente bem organizada;

– Pode ser ensinada e aplicada de modo efetivo;

– Encoraja o desenvolvimento de sistemas bem organizados;

– Ajuda os projetistas a lidar com a complexidade dos sistemas nos estágios iniciais do desenvolvimento.

© LES/PUC-Rio

Limitações da Decomposição Funcional

• Entretanto, a decomposição funcional por refinamentos sucessivos e os métodos de design dela derivados, como a Análise Estruturada, possuem importantes limitações:

– A idéia central destes métodos – a de que um sistema pode ser caracterizado por uma única função – é bastante duvidosa: sistemas reais fornecem aos seus usuários uma série de serviços;

– Usar as propriedades de um sistema mais sujeitas a mudanças – suas funções – como base para a decomposição modular não se coaduna com a natureza evolucionária dos sistemas de software.

© LES/PUC-Rio

A Análise Essencial

• Uma das deficiências da Análise Estruturada, a sua natureza estritamente top-down, foi corrigida pelo método conhecido por Análise Essencial;

• Nesta abordagem, a decomposição funcional é feita tomando-se por base os eventos que ocorrem na interface do sistema com os seus usuários;

• No contexto da Análise Essencial, um evento é definido como um acontecimento no mundo exterior que requer uma resposta do sistema.

© LES/PUC-Rio

Particionamento por Eventos

• Os pares estímulo/resposta são representados na Análise Essencial por um modelo chamado de DFD Particionadopor Eventos:

© LES/PUC-Rio

Limitações da Análise Essencial

• A Análise Essencial corrigiu uma importante deficiência da Análise Estruturada: a natureza estritamente top-downdesta última;

• Entretanto, ela ainda usa as funções de um sistema – suas propriedades mais sujeitas à mudanças – como base para a decomposição modular do mesmo;

• Uma última e importante deficiência de ambas as abordagens será vista a seguir: a obtenção de um modelo hierárquico de módulos a partir do DFD de um sistema.

© LES/PUC-Rio

O Projeto Estruturado (1)

• A derivação do projeto modular a partir do modelo de fluxo de dados é um processo de cinco etapas:

– O tipo de fluxo de informações é estabelecido;

– As fronteiras do fluxo são indicadas;

– O DFD é mapeado para uma estrutura de programa;

– A hierarquia de controle é definida por fatoração;

– A estrutura resultante é aprimorada usando-se medidas e heurísticas de projeto.

© LES/PUC-Rio

Tipos de Fluxos de Dados

• As caracterização dos tipos de fluxos de dados presentes no modelo funcional de um sistema é fundamental para a derivação do seu projeto modular;

• Segundo o Projeto Estruturado, os fluxos de dados de um sistema assumem duas formas básicas

– Fluxo orientado a transformações;

– Fluxo orientado a transação;

© LES/PUC-Rio

Fluxo de Transformações (1)

• Os dados entram no sistema através dos fluxos de entrada;

• Os dados que chegam atravessam um centro de transformação;

• Os dados saem do sistema através dos fluxos de saída;

• O fluxo global de dados ocorre em uma forma seqüencial e segue um ou somente alguns caminhos em uma “linha reta”.

© LES/PUC-Rio

Fluxo de Transformações (2)

© LES/PUC-Rio

Fluxo de Transação (1)

• Caracterizado por um único item de dados, denominado transação, que dispara outro fluxo de dados ao longo de um dentre muitos caminhos;

• A transação é avaliada e, com base no seu valor, o fluxo ao longo de um dos muitos caminhos de ação é iniciado;

• O ponto central do fluxo de informações, a partir do qual muitos caminhos de ação emanam, é denominado centro de transação;

• Grandes sistemas podem apresentar tanto fluxos de transformações como fluxos de transação.

© LES/PUC-Rio

Fluxo de Transação (2)

© LES/PUC-Rio

O Processo do Projeto Estruturado (1)

© LES/PUC-Rio

O Processo do Projeto Estruturado (2)

© LES/PUC-Rio

Análise de Transformações

© LES/PUC-Rio

Fronteiras do Fluxo

© LES/PUC-Rio

Fatoração de 1º Nível (1)

© LES/PUC-Rio


© LES/PUC-Rio

Estrutura de 1º Corte

© LES/PUC-Rio

Estrutura de 2º Corte

© LES/PUC-Rio

Análise de Transação (1)

© LES/PUC-Rio

Análise de Transação (2)

© LES/PUC-Rio

Fatoração de 1º Nível

© LES/PUC-Rio

Fatoração de 2º Nível

© LES/PUC-Rio

Análise do Processo

• A estrutura hierárquica do projeto modular é resultado da natureza top-down da decomposição funcional;

• A abordagem atende bem o objetivo de garantir que o projeto modular atenda as especificações iniciais do problema, mas nenhum esforço é dirigido para promover a reutilização de módulos;

• A derivação do projeto modular é baseada exclusivamente na forma do DFD, não levando em consideração importantes aspectos de uma boa decomposição modular, tais como continuidade e reutilização.

© LES/PUC-Rio





© LES/PUC-Rio

• Na modelagem orientada a objetos a ênfase está na descoberta e na descrição dos objetos – ou conceitos – do domínio de um problema e na representação dos relacionamentos entre os mesmos;

• Neste paradigma, os objetos de domínio devem ser mapeados para objetos de software, que irão colaborar entre si com o objetivo de realizar os requisitos de um sistema.

A Modelagem Orientada a Objetos (1)

© LES/PUC-Rio

A Modelagem Orientada a Objetos (2)

“A modelagem orientada a objetos, usada em conjunto com alguma linguagem orientada a objetos, ajuda a diminuir o gap semântico entre os componentes de software e a concepção humana de um domínio de aplicação, facilitando, assim, a compreensão do design de um sistema”.

© LES/PUC-Rio

O Que Significa UML?

• UML significa Unified Modeling Language;

• É uma linguagem para especificar, visualizar, construire documentar artefatos de software;

• Pode ser usada na modelagem de negócios e em outros tipos de sistemas;

• É uma linguagem visual para modelagem de sistemas.

© LES/PUC-Rio

Sistema de Computação

Processos de Negócios

Item

“A modelagem captura aspartes essenciais do sistema.”

James Rumbaugh

Modelagem visual significa modelar com a utilização de notaçõespadronizadas.

Pedido

Envio

O Que é Modelagem Visual?

© LES/PUC-Rio

A modelagem visual favorece o entendimento das regras de negócio e a representação das mesmas em um design orientado a objetos.

Ferramenta de Comunicação

© LES/PUC-Rio

A UML é uma Linguagem

• Uma linguagem fornece um vocabulário, e as regras para a combinação de “palavras” desse vocabulário, com o objetivo de comunicar algo;

• Uma linguagem de modelagem é uma linguagem cujo vocabulário e as regras têm seu foco voltado para a representação conceitual e física de um sistema;

• O vocabulário e as regras de uma linguagem de modelagem indicam como criar e ler modelos bem formados, mas não apontam quais modelos devem ser criados e nem em que seqüência.

© LES/PUC-Rio

A UML para Visualização e Especificação

• UML facilita a construção de modelos visuais de um sistema, especificando a sua estrutura (parte estática ) e ao seu comportamento (parte dinâmica);

• A UML fornece os símbolos gráficos para a representação de artefatos de software;

• Por trás de cada símbolo empregado na notação da UML, existe sintaxe e semântica bem-definidas;

• Dessa forma, a UML favorece a construção de modelos precisos, completos e sem ambigüidades.

© LES/PUC-Rio

A UML para Construir

• Os modelos de UML podem ser diretamente ”traduzidos”para várias linguagens de programação;

• Isso significa que é possível mapear os modelos da UML para linguagens de programação tais como, Java, C++ e C#;

• Esse mapeamento permite a realização de uma engenharia de produção (geração de código) a partir de modelos UML;

• É possível também reconstruir alguns modelos a partir do código fonte escrito em alguma linguagem de programação. Este processo inverso é chamado de engenharia reversa.

© LES/PUC-Rio

A UML para Documentar

• Os requisitos do sistema;

• A arquitetura do sistema e todos os seus detalhes;

• As atividades de planejamento do projeto;

• As atividades de realização de testes;

• O gerenciamento de versões.

© LES/PUC-Rio

As Vantagens da UML

• Padrão aberto e não proprietário (OMG);

• Independência do processo de desenvolvimento;

• Aplicável a todas as fases do ciclo de desenvolvimento;

• Independência da linguagem de programação;

• Integração das melhores práticas de modelagem;

• É uma linguagem extensível.

© LES/PUC-Rio

Interface com o usuário(Swing, .NET, HTML)

Projete o seu sistemaindependente da

tecnologia de implementação

Persistência (SQL, EJB, Hibernate)

Lógica do negócio(Java, C++, C#)

Suporte a Diferentes Tecnologias

© LES/PUC-Rio

Múltiplas Plataformas

Componentes Reutilizáveis

Promoção da Reutilização

© LES/PUC-Rio

A História da UML (1)

• É o resultado da unificação das notações utilizadas nos métodos Booch, OMT (Object Modeling Technique) e OOSE (Object-Oriented Software Engineering);

• Adotada como linguagem padrão de modelagem por grande parte da indústria de software e por fornecedores de ferramentas CASE.

© LES/PUC-Rio

A História da UML (2)

© LES/PUC-Rio

Descrição da Arquitetura

• Diferentes participantes – usuários finais, analistas, programadores, equipe de testes, gerentes de sistemas e etc. – têm visões e interesses distintos em relação a um sistema;

• Cada um destes participantes traz contribuições próprias ao projeto, em diferentes momentos ao longo do desenvolvimento;

• A descrição da arquitetura do sistema deve permitir o gerenciamento adequado destes diferentes pontos de vista ao logo do ciclo de vida de um sistema.

© LES/PUC-Rio

O Que é Arquitetura?

• A arquitetura é o conjunto de decisões significativas sobre:

– A organização do sistema de software;

– A seleção dos elementos estruturais que compõem o sistema;

– O comportamento do sistema, conforme especificado nas colaborações entre esses elementos;

– A decomposição desses elementos estruturais e comportamentais em subsistemas progressivamente maiores;

– O estilo arquitetural que orienta a organização: os elementos estáticos e dinâmicos, suas interfaces, colaborações e composições.

© LES/PUC-Rio

A arquitetura de um sistema

complexo pode ser descrita

mais adequadamente através

de cinco visões

complementares:

Visões da Arquitetura

© LES/PUC-Rio

Descreve o sistema de um ponto

de vista externo como um conjunto

de interações entre o sistema e os

agentes externos ao sistema.

Visão de Casos de Uso (1)

© LES/PUC-Rio

• Descrição textual

• Diagramas de casos de uso

• Diagramas de estados

• Diagramas de interações

• Diagramas de atividades

Utiliza os seguintes recursos:

Visão de Casos de Uso (2)

© LES/PUC-Rio

Enfatiza as características do

sistema que dão suporte, tanto

estrutural quanto comportamental,

às funcionalidades externamente

visíveis do sistema.

Visão de Projeto (1)

© LES/PUC-Rio

• Diagramas de classes




Visão de Projeto (2)

© LES/PUC-Rio

Mostra o fluxo de controle entre as

várias partes, incluindo

mecanismos de concorrência e

sincronização. Essa visão cuida

principalmente das questões

referentes ao desempenho, à

escalabilidade e ao throughput do

sistema.

Visão de Processos (1)

© LES/PUC-Rio

Utiliza os mesmos diagramas da

visão de projeto, mas com o foco

voltado para as classes ativas

(processos ou threads) que

controlam o sistema e as

mensagens que passam por elas.

Visão de Processos (2)

© LES/PUC-Rio

Abrange o gerenciamento de

versões de um sistema e dos

componentes e artefatos utilizados

para a montagem e distribuição do

mesmo. Diz respeito também ao

mapeamento dos componentes

lógicos para os artefatos físicos.

Visão de Implementação (1)

© LES/PUC-Rio

• Diagramas de componentes





Visão de Implementação (2)

© LES/PUC-Rio

Abrange os nós que formam a

topologia do hardware onde o

sistema será executado. Essa

visão trata principalmente da

distribuição, do fornecimento e da

instalação dos componentes

físicos de um sistema.

Visão de Implantação (1)

© LES/PUC-Rio

• Diagramas de implantação





Visão de Implantação (2)

© LES/PUC-Rio

Bibliografia (1)

• Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 1ª edição, Campus, 2006.

• Larman, C. Utilizando UML e Padrões. 3ª edição, Bookman, 2007.

• Meyer, B. Object-Oriented Software Construction. 2nd edition, Prentice Hall PTR, 2000.

• Page-Jones, M. Practical Guide to Structured SystemsDesign. 2nd edition, Prentice Hall PTR, 1988.

© LES/PUC-Rio

Bibliografia (2)

• Pressman, R.S. Software Engineering: A Practitioner'sApproach. 5th edition. McGraw-Hill, 2003.

INF1404 – MODELAGEM DE SISTEMAS - inf.puc-rio.brivan/PROMINP/NotasAula/MS-CAP-01.pdf ·...

Documents

Transcript of INF1404 – MODELAGEM DE SISTEMAS - inf.puc-rio.brivan/PROMINP/NotasAula/MS-CAP-01.pdf ·...