INF1404 MODELAGEM DE SISTEMAS

Transcrição

1 INF1404 MODELAGEM DE SISTEMAS Bacharelado em Sistemas de Informação Ivan Mathias Filho Programa Capítulo 1 Princípios de Modelagem O Paradigma Funcional O Paradigma Orientado a Objetos

2 Programa Capítulo 1 Princípios de Modelagem O Paradigma Funcional O Paradigma Orientado a Objetos A Importância da Modelagem (1) Sistemas de pouca complexidade podem ser construídos sem um planejamento prévio.

3 A Importância da Modelagem (2) Sistemas complexos exigem planejamento rigoroso e trabalho em equipe. O Que é um Modelo? Um modelo é uma simplificação da realidade.

4 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. Controle da Complexidade

5 Controle da Complexidade 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.

6 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. Múltiplas Visões (1) Projetos complexos demandam modelos com diferentes níveis de precisão.

7 Múltiplas Visões (2) Visões distintas e quase independentes de um sistema complexo nos ajudam na sua investigação. Programa Capítulo 1 Princípios de Modelagem O Paradigma Funcional O Paradigma Orientado a Objetos

8 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: 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:

9 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 Decomposição Funcional (2) Se optarmos por um pseudo-linguagem de programação, a decomposição anterior assumiria a seguinte forma: início inicialize 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-enquanto calcule salário bruto; calcule impostos e salário líquido; imprima contracheque; leia arquivo de funcionários; fim-enquanto imprima relatório com os totais de pagamento; feche os arquivos; fim

10 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. 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):

11 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. 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.

12 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. Particionamento por Eventos Os pares estímulo/resposta são representados na Análise Essencial por um modelo chamado de DFD Particionado por Eventos:

13 Limitações da Análise Essencial A Análise Essencial corrigiu uma importante deficiência da Análise Estruturada: a natureza estritamente top-down desta ú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. 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.

14 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; 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.

15 Fluxo de Transformações (2) 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.

16 Fluxo de Transação (2) O Processo do Projeto Estruturado (1)

17 O Processo do Projeto Estruturado (2) Análise de Transformações

18 Fronteiras do Fluxo Fatoração de 1º Nível (1)

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

20 Fatoração de 2º Nível (2) Estrutura de 1º Corte

21 Estrutura de 2º Corte Análise de Transação (1)

22 Análise de Transação (2) Fatoração de 1º Nível

23 Fatoração de 2º Nível 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.

24 Programa Capítulo 1 Princípios de Modelagem O Paradigma Funcional O Paradigma Orientado a Objetos A Modelagem Orientada a Objetos (1) 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.

25 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. O Que Significa UML? UML significa Unified Modeling Language; É uma linguagem para especificar, visualizar, construir e 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.

26 O Que é Modelagem Visual? Pedido Item A modelagem captura as partes essenciais do sistema. James Rumbaugh Envio Processos de Negócios Modelagem visual significa modelar com a utilização de notações padronizadas. Sistema de Computação Ferramenta de Comunicação A modelagem visual favorece o entendimento das regras de negócio e a representação das mesmas em um design orientado a objetos.

27 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. 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.

28 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. 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.

29 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. Suporte a Diferentes Tecnologias Interface com o usuário (Swing,.NET, HTML) Lógica do negócio (Java, C++, C#) Persistência (SQL, EJB, Hibernate) Projete o seu sistema independente da tecnologia de implementação

30 Promoção da Reutilização Múltiplas Plataformas Componentes Reutilizáveis 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.

31 A História da UML (2) 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.

32 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. Visões da Arquitetura A arquitetura de um sistema complexo pode ser descrita mais adequadamente através de cinco visões complementares:

33 Visão de Casos de Uso (1) 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 (2) Utiliza os seguintes recursos: Descrição textual Diagramas de casos de uso Diagramas de estados Diagramas de interações Diagramas de atividades

34 Visão de Projeto (1) 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 (2) Utiliza os seguintes recursos: Diagramas de classes Diagramas de interações Diagramas de estados

35 Visão de Processos (1) 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 (2) 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.

36 Visão de Implementação (1) 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 (2) Utiliza os seguintes recursos: Diagramas de componentes Diagramas de interações Diagramas de estados Diagramas de atividades

37 Visão de Implantação (1) 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 (2) Utiliza os seguintes recursos: Diagramas de implantação Diagramas de interações Diagramas de estados Diagramas de atividades

38 Bibliografia (1) Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 1ª edição, Campus, Larman, C. Utilizando UML e Padrões. 3ª edição, Bookman, Meyer, B. Object-Oriented Software Construction. 2nd edition, Prentice Hall PTR, Page-Jones, M. Practical Guide to Structured Systems Design. 2nd edition, Prentice Hall PTR, Bibliografia (2) Pressman, R.S. Software Engineering: A Practitioner's Approach. 5th edition. McGraw-Hill, 2003.

39 Exemplo Descrição de Caso de Uso Exemplo Diagrama de Casos de Uso

40 Exemplo Diagrama de Estados Exemplo Diagrama de Interação

41 Exemplo Diagrama de Atividades Exemplo Diagrama de Classes

42 Exemplo Diagrama de Atividades Exemplo Diagrama de Interação

43 Exemplo Diagrama de Componentes Exemplo Diagrama de Implantação