1 / 67

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

Breve Histórico de Linguagens e Metodologias de Modelagem de Software. Linguagens de Modelagem de SW. Formais , Informais , Semi- formais Algébricas , Visuais. Algumas linguagens / processos apresentados brevemente. Fluxograma Análise Estruturada e suas extensões IDEFs Z VDM

quade
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BreveHistórico de Linguagens e Metodologias de Modelagem de Software

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

  3. Algumaslinguagens/processosapresentadosbrevemente • Fluxograma • AnáliseEstruturada e suasextensões • IDEFs • Z • VDM • B • Modelica • Alloy • Statecharts • SDL • Álgebra de Processos (ACP, CCS, CSP) • Redes de Petri • SysML • UML

  4. Fluxogramas • Usadodesde a década de 1940 paraespecificar software • Muitousadonasdécadas de 1960 e 1970 • Flowchrating techniques (IBM 1969): http://www.fh-jena.de/~kleine/history/software/IBM-FlowchartingTechniques-GC20-8152-1.pdf

  5. Fluxogramas

  6. Fluxogramas • Caiuemdesuso com as técnicasestruturadas • Masainda é usadoparaespecificação de processos e software.

  7. AnáliseEstruturada • Diversosautores • 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áliseEstruturada • Idéias estruturadas de 1960 e 1970’s • Structured program theorem (Böhm-Jacopini theorem - 1966) – “Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules" (May 1966). Comm. ACM, 9(5):366-371 • 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áliseEstruturada • Programaçãoestruturada • 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áliseEstruturadaparaSistemas 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. FerramentasdaAnáliseEstruturada • Diagrama de Fluxo de Dados • Dicionário de Dados • Pseudo-código/Linguagemestruturada • Árvores de decisão • Tabelas de Decisão • DiagramaEntidade-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 -> 1.1 -> 1.1.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

  27. Vantagens • Análise top-down • Múltiplosníveis de detalhe • Múltiplasvisões (fluxo de dados, pseudo-código, dados, tabelas de decisão)

  28. Problemas • “Bolhasnãotravam” • 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 • Família de linguagens de modelagem (Algumasaindaemdesenvolvimento) • 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 ArtifactModeling • IDEF12 : Organization Modeling • IDEF13 : Three Schema Mapping Design • IDEF14 : Network Design • http://www.idef.com/Home.htm

  30. IDEF0 • Linguagem de modelagemfuncionalpara • 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 naprática • IBM CICS • servidor de transações • Middleware quesuporta alto volume de transações • Criadoparapossibilitarprocessamento 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 naprática • Parte do IBM CICS foiformalizadousando Z nasdécadas de 1980s e 1990s emcolaboração com o Oxford University Computing Laboratory • Sir Tony Hoare • Quicksort • Hoare Logic • CSP (Communicating Sequential Processes)

  36. Z e Orientação a objetos • Z++ • 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) • Originadona IBM de Vienna, nadécada de 1970. 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 • Usadoemsistemas de missãocrítica • Menorabstraçãoque 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 • https://www.modelica.org/

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

  41. Alloy • Software Design Groupat 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 • AlloyAnalyzer

  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çãonãoambigua e descrição do comportamento de sistemasdistribuídos de tempo real • Origemnossistemas de telecomunicações • Gráfica e algébrica • http://www.sdl-forum.org/

  46. Álgebra de Processos • Process Algebra • Process Calculus • Família de linguagens para modelar formalmente sistemas concorrentes • Principais: CSP, CCS, ACP • Histórico: http://www.informatik.hs-mannheim.de/~schramm/CSP/files/historyProcessAlgebra.pdf

  47. Conceitos • Processo: comportamento de um sistema • Algebra: conceitosalgébricosparamodelarcomportamento • Process algebra: the study of the behaviour of parallel or distributed systems by algebraic means • Possibilidades de verificação: • Estabelecer se um sistemasatisfazdeterminadapropriedade.

  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

More Related