inf1404 – modelagem de sistemas - inf.puc-rio.brivan/prominp/notasaula/ms-cap-01.pdf ·...
TRANSCRIPT
INF1404 – MODELAGEM DE SISTEMAS
Bacharelado em Sistemas de Informação
Ivan Mathias Filho
© LES/PUC-Rio
Programa – Capítulo 1
• Princípios de Modelagem
• O Paradigma Funcional
• O Paradigma Orientado a Objetos
© LES/PUC-Rio
Programa – Capítulo 1
• Princípios de Modelagem
• O Paradigma Funcional
• O Paradigma Orientado a Objetos
© 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
Programa – Capítulo 1
• Princípios de Modelagem
• O Paradigma Funcional
• O Paradigma Orientado a Objetos
© 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
Fatoração de 1º Nível (2)
© LES/PUC-Rio
Fatoração de 2º Nível (1)
© LES/PUC-Rio
Fatoração de 2º Nível (2)
© 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
Programa – Capítulo 1
• Princípios de Modelagem
• O Paradigma Funcional
• O Paradigma Orientado a Objetos
© 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
• Diagramas de interações
• Diagramas de estados
Utiliza os seguintes recursos:
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
• Diagramas de interações
• Diagramas de estados
• Diagramas de atividades
Utiliza os seguintes recursos:
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
• Diagramas de interações
• Diagramas de estados
• Diagramas de atividades
Utiliza os seguintes recursos:
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.
© LES/PUC-Rio
Exemplo – Descrição de Caso de Uso
© LES/PUC-Rio
Exemplo – Diagrama de Casos de Uso
© LES/PUC-Rio
Exemplo – Diagrama de Estados
© LES/PUC-Rio
Exemplo – Diagrama de Interação
© LES/PUC-Rio
Exemplo – Diagrama de Atividades
© LES/PUC-Rio
Exemplo – Diagrama de Classes
© LES/PUC-Rio
Exemplo – Diagrama de Atividades
© LES/PUC-Rio
Exemplo – Diagrama de Interação
© LES/PUC-Rio
Exemplo – Diagrama de Componentes
© LES/PUC-Rio
Exemplo – Diagrama de Implantação