Breve Histórico de Linguagens e Metodologias de Modelagem de Software

Apresentação em tema: "Breve Histórico de Linguagens e Metodologias de Modelagem de Software"— Transcrição da apresentação:

1 Breve Histórico de Linguagens e Metodologias de Modelagem de Software

2 Linguagens de Modelagem de SW
Formais, Informais, Semi-formais Algébricas, Visuais

3 Algumas linguagens/processos apresentados brevemente
Fluxograma Análise Estruturada e suas extensões IDEFs Z VDM B Modelica Alloy Statecharts SDL Álgebra de Processos (ACP, CCS, CSP) Redes de Petri SysML UML

4 Fluxogramas Usado desde a década de 1940 para especificar software
Muito usado nas décadas de 1960 e 1970 Flowchrating techniques (IBM 1969):

5 Fluxogramas

6 Fluxogramas Caiu em desuso com as técnicas estruturadas
Mas ainda é usado para especificação de processos e software.

7 Análise Estruturada Diversos autores
Larry Constantine and Ed Yourdon (1975). Structured Design. Yourdon Press. Chris Gane and Trish Sarson. Structured Systems Analysis: Tools and Techniques. McDonnell Douglas Systems Integration Company, 1977 Tom DeMarco (1979). Structured Analysis and System Specification. Prentice Hall. Edward Yourdon (1989). Modern Structured Analysis, Yourdon Press Computing Series, 1989

8 Análise Estruturada Idéias estruturadas de 1960 e 1970’s
Structured program theorem (Böhm-Jacopini theorem ) – “Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules" (May 1966). Comm. ACM, 9(5): Any algorithm can be expressed using only three control structures. They are Executing one subprogram, and then another subprogram (sequence) Executing one of two subprograms according to the value of a boolean expression (selection) Executing a subprogram until a boolean expression is true (iteration)

9 Análise Estruturada Programação estruturada
Go To Statement Considered Harmful (Dijsktra, 1968) "The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program." O.-J. Dahl, E. W. Dijkstra, C. A. R. Hoare Structured Programming, Academic Press, London, 1972 Algol, Pascal, C

10 Análise Estruturada para Sistemas de Tempo de Real
Inclusão de diagrama de fluxo de controle Derek J. Hatley, Imtiaz A. Pirbhai (1988). Strategies for Real Time System Specification. John Wiley and Sons Ltd. Stephen J. Mellor und Paul T. Ward (1986). Structured Development for Real-Time Systems: Implementation Modeling Techniques: 003. Prentice Hall.

11 Ferramentas da Análise Estruturada
Diagrama de Fluxo de Dados Dicionário de Dados Pseudo-código/Linguagem estruturada Árvores de decisão Tabelas de Decisão Diagrama Entidade-Relacionamento

12 Diagrama de Fluxo de Dados
Modelo lógico do software Independente de hardware, software, estrutura de dados... Pode ser particionado em diversos níveis de abstração (Contexto ou nível 0, nível 1, ...) 4 elementos básicos Entidade externa (origem/destino) Processo Depósito de dados Fluxo de dados

13 Entidade Externa Define a origem ou o destino dos dados
Normalmente é uma pessoa ou grupo de pessoas, uma organização, ou parte dela, um hardware ou software Produz e recebe informação

14 Processo Transforma dados
Pode representar um software, vários softwares, um módulo, ... Geralmente provoca mudança de estado, estrutura ou conteúdo A numeração não indica sequência de ações Geralmente são verbos na especificação

15 Depósito de dados Pode ser um arquivo, uma tabela, ou parte de um banco de dados Independente de unidade de armazenamento Pode receber o nome do fluxo de dados Normalmente está no plural

16 Fluxo de Dados Insere e retira dados de processos, depósitos de dados e entidades externas Deve ter um nome único Deve ser descrito no dicionário de dados

17 DFD de Contexto DFD de nível mais alto (DFD de nível 0)
Apresenta a visão das principais funções do sistema Contém um processo, entidades externas e fluxos de dados

18 Níveis de DFD Seguem DFD's de nível 1, 2, ...
A quantidade de níveis depende da complexidade do software Quantos níveis são necessários? O suficiente :) Experiência dos desenvolvedores Numerações: 1 -> > > ...

19 Explosão de DFD’s Uma vez identificadas as funções principais, pode-se explodir cada função para níveis mais detalhados A explosão é uma decomposição hierárquica 7+-2 processos por nível

20 Dicionário de dados Descrição de dados do software
Ajuda a melhorar a comunicação usuário/analista Usado na base de dados Significado de fluxos e depósitos de dados Composição de dados agregados (endereço, identificação, ...)

21 Dicionário de Dados – Esquema de Documentação
= é composto de + Concatenação {}n repetição [ | | | ] escolha de alternativas () opcional Ex.: nome = [Sr.| Sra.|Srta.] + família + nome

22 Linguagem Estruturada
Notação algoritmica para especificar o comportamento dos processos Sequência: fazer, calcular, ler, gravar, ... Decisão: se então se então senão Repetição: repetir até enquanto faça

23 Criação de DFD’s a partir de especificações
Verbos geralmente originam processos Substantivos são entidades externas, dados ou depósitos de dados O refinamento deve seguir até o processo realizar uma única função

24 Diagrama Entidade-Relacionamento
Modela os dados identificados, juntamente com seus atributos e relacionamentos Foco da disciplina Banco de Dados

25 Árvores de Decisão

26 Tabelas de Decisão TABELA-CASACO R1 R2 R3 R4 C1 C2 Chovendo frio Y N
usar capa forrada X A2 usar capa sem forro A3 usar pulover de lã A4 prossiga para a garagem X1 retorne à tabela mestra

27 Vantagens Análise top-down Múltiplos níveis de detalhe
Múltiplas visões (fluxo de dados, pseudo-código, dados, tabelas de decisão)

28 Problemas “Bolhas não travam” Não mostra
Tempo de execução de processos Tempo de transferência de dados nos fluxos Paralelismo de execução de processos Necessariamente sequencia Caiu em desuso com a orientação a objetos e os sistemas on-line Ainda é usada em novos sistemas Existe muita documentação em sistemas legados

29 IDEF http://www.idef.com/Home.htm
Família de linguagens de modelagem (Algumas ainda em desenvolvimento) IDEF0 : Function modeling IDEF1 : Information Modeling IDEF1X : Data Modeling IDEF2 : Simulation Model Design IDEF3 : Process Description Capture IDEF4 : Object-Oriented Design IDEF5 : Ontology Description Capture IDEF6 : Design Rationale Capture IDEF7 : Information System Auditing IDEF8 : User Interface Modeling IDEF9 : Business Constraint Discovery IDEF10 : Implementation Architecture Modeling IDEF11 : Information Artifact Modeling IDEF12 : Organization Modeling IDEF13 : Three Schema Mapping Design IDEF14 : Network Design

30 IDEF0 Linguagem de modelagem funcional para Análise Desenvolvimento
Reengenharia Integração

31 IDEF0

32 IDEF1X Modelagem de dados

33 Notação Z Baseado na teoria de Zermelo–Fraenkel e na lógica de predicados Final da década de 1970, em Oxford Jean-Raymond Abrial Z usa muitos símbolos não ASCII uso de ferramentas/LATEX

34 Z na prática IBM CICS servidor de transações
Middleware que suporta alto volume de transações Criado para possibilitar processamento on-line 30 billion+ transactions a day $1 trillion in transactions each day 30 million users worldwide 900,000 concurrent users supported 90% + of the Fortune 500

35 Z na prática Parte do IBM CICS foi formalizado usando Z nas décadas de 1980s e 1990s em colaboração com o Oxford University Computing Laboratory Sir Tony Hoare Quicksort Hoare Logic CSP (Communicating Sequential Processes)

36 Z e Orientação a objetos
Lano, K.C., Z++, an Object-Oriented Extension to Z. Z User Workshop, Oxford 1990 Object Z Graeme Smith. The Object-Z Specification Language. Kluwer Academic Publishers, 2000 Roger Duke and Gordon Rose. Formal Object-Oriented Specification Using Object-Z. MacMillan, 2000.

37 Vienna Development Method (VDM)
Originado na IBM de Vienna, na década de Envolve: Técnicas Ferramentas Linguagem "Systematic Software Development using VDM" by Cliff Jones, 2nd edn., Prentice Hall 1990. VDM++

38 B method Jean-Raymond Abrial
The B-Book: Assigning Programs to Meanings, Jean-Raymond Abrial, Cambridge University Press, 1996 Usado em sistemas de missão crítica Menor abstração que Z

39 Modelica Linguagem de modelagem para sistemas complexos (1997)
componentes eletrônicos, mecânicos, hidráulicos, de controle, ... Modelo parecido com POO equações diferenciais, algébricas e discretas Chamadas de C, FORTRAN, Java Engine de simulação

40 Modelica https://www.modelica.org/documents/ModelicaSpec33.pdf
Usada por: Audi, BMW, Daimler, Ford, Toyota, VW ABB, EDF, Siemens.

41 Alloy Software Design Group at MIT lead by Professor Daniel Jackson (1997) Linguagem de especificação declarativa Comportamento estrutural e dinâmico Baseado em lógica de predicados Sintaxe baseada em Z Alloy Analyzer

42 Statecharts Harel, D. (1987). A Visual Formalism for Complex Systems. Science of Computer Programming , 231–274. Extensão das máquinas de estado Foco: especificação de sistemas complexos a eventos discretos Base para o diagrama de estados da UML

43 Statecharts - Características
Extensão das máquinas de estado noção de hierarquia concorrência e paralelismo comunicação Compactos Possibilidade de composição Modular Descrição em diferentes níveis de abstração

44 Statecharts statecharts = state-diagrams + depth + orthogonality + broadcast-communication

45 SDL Specification and Description Language (SDL)
Foco: especificação não ambigua e descrição do comportamento de sistemas distribuídos de tempo real Origem nos sistemas de telecomunicações Gráfica e algébrica

46 Álgebra de Processos Process Algebra Process Calculus
Família de linguagens para modelar formalmente sistemas concorrentes Principais: CSP, CCS, ACP Histórico:

47 Conceitos Processo: comportamento de um sistema
Algebra: conceitos algébricos para modelar comportamento Process algebra: the study of the behaviour of parallel or distributed systems by algebraic means Possibilidades de verificação: Estabelecer se um sistema satisfaz determinada propriedade.

48 CCS CCS - Calculus of Communicating Systems
Robin Milner: A Calculus of Communicating Systems, Springer Verlag, 1980. Desenvolvido entre 1973 e 1980

49 CSP CSP - Communicating Sequential Processes
Tony Hoare - Communicating sequential processes. Communications of the ACM, 21(8):666–677, 1978 Knighthood (for services to Computing Science). March 7, 2000.

50 ACP ACP - Algebra of Communicating Processes 1982
Jan Bergstra e Jan Willem Klop. Fixed point semantics in process algebra. Technical Report IW 208, Mathematical Centre, Amsterdam

51 Redes de Petri Linguagem gráfica e matemática para modelagem de sistemas Tese de Carl Petri, 1962 Teoria básica desenvolvida na década de 1970 A.W. Holt (MIT )

52 Redes de Petri - Aplicação
Modelagem e análise de sistemas distribuídos banco de dados distribuídos paralelismo e concorrência em software manufatura sistemas de controle sistemas operacionais workflow organizacional logística redes neurais sistemas de apoio a decisão

53 Redes de Petri – Forma de apresentação
Gráfica Matriz Relações

54 Redes de Petri - Modelagem
Sequência Paralelismo Sincronismo/Assincronismo Recursos Repetição Competição/Conflitos Buffer

55 Redes de Petri - Análise
Avaliação de propriedades: Alcançabilidade de estados Limitabilidade Análise de deadlocks/livelocks Reversibilidade

56 Redes de Petri – Métodos de análise
Árvore de cobertura Invariantes de lugar e transição Lógica linear

57 Extensões Tempo associado a lugares, transições, fichas Fuzzy
Timed Time Fuzzy Estocástica Orientada a Objetos Colorida Arco inibidor Reset Arc Contínua Híbrida

58 SysML Linguagem gráfica para modelagem de sistemas que incluem hardware, software, dados, pessoas, procedimentos Profile da UML

59 Relação UML-SysML

60 Relação UML-SysML

61 UML Evolução de outros métodos/linguagens
“A UML é a linguagem padrão para visualizar, especificar, construir e documentar os artefatos de software de um sistema.”

62 UML UML é... uma linguagem visual. independente de linguagem de programação. independente de processo de desenvolvimento. UML não é... uma linguagem programação um processo de desenvolvimento. Os artefatos gráficos produzidos de um sistema OO são definidos através dos diagramas da UML.

63

64 Diagramas da UML

65 O que dizem sobre a UML? It contains many diagrams and constructs that are redundant or infrequently used. The standards have been cited as being ambiguous and inconsistent. While the XMI (XML Metadata Interchange) standard is designed to facilitate the interchange of UML models, it has been largely ineffective in the practical interchange of UML 2.x models. UML is not enough for the modeling of embedded and real-time systems.

66 O que dizem sobre a UML? The UML specification, in general, is semiformal. This lack of precise semantics can lead to severe problems, as different or ambiguous interpretations. If UML is nothing else it is for documentation and communication. UML is not perfect, but it is the most common, is good enough, and not trivially replaceable A UML não é perfeita, mas é o que temos de melhor em termos de modelagem de SW atualmente

67 Leitura Art 9 - Seven myths of formal methods
Art 10 - Seven more myths of formal methods 2 páginas no total