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

Post on 23-Feb-2016

34 views 0 download

description

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 - PowerPoint PPT Presentation

Transcript of 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• B• Modelica• Alloy• Statecharts• SDL• Álgebra de Processos (ACP, CCS, CSP)• Redes de Petri• SysML• UML

Fluxogramas

• Usado desde a década de 1940 para especificar software

• Muito usado nas décadas de 1960 e 1970• Flowchrating techniques (IBM 1969):

http://www.fh-jena.de/~kleine/history/software/IBM-FlowchartingTechniques-GC20-8152-1.pdf

Fluxogramas

Fluxogramas

• Caiu em desuso com as técnicas estruturadas– Mas ainda é usado para especificação de

processos e software.

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

Análise Estruturada

• 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)

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

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.

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

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

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

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

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

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

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

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

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

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, ...)

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

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

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

Diagrama Entidade-Relacionamento

• Modela os dados identificados, juntamente com seus atributos e relacionamentos

• Foco da disciplina Banco de Dados

Árvores de Decisão

Tabelas de DecisãoTABELA-CASACO R1 R2 R3 R4

C1C2

Chovendofrio

YY

YN

NY

NN

A1 usar capa forrada X

A2 usar capa sem forro X

A3 usar pulover de lã X

A4 prossiga para a garagem X X X X

X1 retorne à tabela mestra X X X X

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)

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

IDEF• 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

• http://www.idef.com/Home.htm

IDEF0

• Linguagem de modelagem funcional para– Análise– Desenvolvimento– Reengenharia– Integração

IDEF0

IDEF1X

• Modelagem de dados

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

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

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)

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.

Vienna Development Method (VDM)

• Originado na IBM de Vienna, na década de 1970. Envolve:– Técnicas– Ferramentas – Linguagem

• "Systematic Software Development using VDM" by Cliff Jones, 2nd edn., Prentice Hall 1990.

• VDM++

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

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/

Modelica

• https://www.modelica.org/documents/ModelicaSpec33.pdf

• Usada por: Audi, BMW, Daimler, Ford, Toyota, VW ABB, EDF, Siemens.

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

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

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

Statecharts

• statecharts = state-diagrams + depth + orthogonality + broadcast-communication

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• http://www.sdl-forum.org/

Á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

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.

CCS

• CCS - Calculus of Communicating Systems

• Robin Milner: A Calculus of Communicating Systems, Springer Verlag, 1980.

• Desenvolvido entre 1973 e 1980

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.

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

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 )

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

Redes de Petri – Forma de apresentação

• Gráfica• Matriz• Relações

Redes de Petri - Modelagem

• Sequência• Paralelismo• Sincronismo/Assincronismo• Recursos• Repetição• Competição/Conflitos• Buffer

Redes de Petri - Análise

• Avaliação de propriedades:– Alcançabilidade de estados– Limitabilidade– Análise de deadlocks/livelocks– Reversibilidade

Redes de Petri – Métodos de análise

• Árvore de cobertura• Invariantes de lugar e transição• Lógica linear

Extensões • Tempo associado a lugares, transições, fichas

– Timed– Time

• Fuzzy• Estocástica• Orientada a Objetos• Colorida• Arco inibidor• Reset Arc• Contínua• Híbrida

SysML

• Linguagem gráfica para modelagem de sistemas que incluem hardware, software, dados, pessoas, procedimentos

• Profile da UML

Relação UML-SysMLUML 2

UML 2Reuse(1, 2)

UMLreused by

SysML

UMLnot required

by SysML(UML -

UML4SysML)

SysMLextensions to

UML

SysML

Relação UML-SysML

SysML Diagrams

Behavior Diagrams

Requirements Diagrams

Structure Diagrams

Activity Diagram

Sequence Diagram

State Machine Diagram

Use Case Diagram

Block Definition Diagram

Internal Block

Diagram

Package Diagram

Parametric Diagram

Modified from UML2

New diagram

Same as UML2

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

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.

Diagramas da UML

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.

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

Leitura

• Art 9 - Seven myths of formal methods• Art 10 - Seven more myths of formal methods

– 2 páginas no total