Upload
trinhkhanh
View
214
Download
0
Embed Size (px)
Citation preview
Projeto de Software
Silvia Regina Vergilio - UFPR
1) Objetivos
Modelos de representação do domínio (análise)
⇓ Técnicas e princípios
Detalhe suficiente para permitir a realização física do sistema (implementação)
2) Importância Fase na qual a qualidade é criada
e poderá ser efetivamente avaliada.
Servirá como fundamento para as fases de codificação, teste e manutenção.
2) Importância
2) Importância
“ ... tentamos resolver o problema passando rapidamente pelo processo de projeto para que sobre tempo suficiente no final para detectar e corrigir defeitos que foram introduzidos porque dedicamos pouco tempo ao projeto.”
3) Fundamentos (Princípios)
1. Refinamento (análogo ao princípio do particionamento) – decomposição
2. Arquitetura do software: um problema P pode ser solucionado por muitas estruturas candidatas
3) Fundamentos (Princípios)
________________
3) Fundamentos (Princípios)
3) Fundamentos (Princípios) Módulo que controla um módulo:
superior Módulo controlado por outro:
subordinado Largura – abertura (amplitude) da
estrutura Profundidade – número de níveis
de controle
3) Fundamentos (Princípios) Fan-out: número de módulos
controlados por um dado módulo Fan-in: número de módulos que
controlam um dado módulo
Visibilidade – conjunto de componentes invocados ou utilizados até mesmo indiretamente
Conectividade: conjunto de componentes diretamente invocados ou utilizados
3) Fundamentos (Princípios)
3. Modularidade: característica do software que permite a sua inteligibilidade, permite dividí-lo em componentes menores, chamados módulos.
3) Fundamentos (Princípios)3. Modularidade: Leva a um esforço menor
para resolver problemas C(x)=complexidade do problema E(x)=esforço para resolver o problemaC(P1) > C(P2) E(P1) > E(P2)C(P1+P2) >C(P1)+C(P2) E(P1+P2)>E(P1) + E(P2)
Como saber se eu dividi o suficiente?
3) Fundamentos (Princípios)4. Abstração – diferentes níveis
5. Ocultamento da Informação: princípio que diz que módulos devem ser especificados e projetados de modo que a informação (dados ou procedimento) nele contida seja inacessível a outros módulos que não tenham necessidade daquela informação
3) Fundamentos (Princípios) Coesão e Acoplamento
Baseadas nos princípios de um bom projeto: (Yourdon, Constantine e Myers)
Coesão: medida da funcionalidade de um módulo; o quanto ele realiza uma tarefa específica
Acoplamento: mede o grau de interdependência entre módulos
3) Fundamentos (Princípios) Coesão e Acoplamento
3) Fundamentos (Princípios) Coesão (Deve ser alta) coincidente: o módulo realiza funções
não relacionadas
lógica: as funções estão relacionadas logicamente
temporal: o módulo realiza mais que uma função que devem ocorrer no mesmo intervalo de tempo
3) Fundamentos (Princípios) Coesão procedimental: o módulo realiza mais que
uma função, de tal forma que elas estão relacionadas a um procedimento geral
comunicacional: o módulo realiza funções que manipulam a mesma estrutura de dados
funcional: o módulo realiza uma única função bem definida
3) Fundamentos (Princípios) Acoplamento (Deve ser baixo) acoplamento por conteúdo: x faz
referência direta ao interior de y
acoplamento por common: x e y referenciam variáveis globais
acoplamento por controle: x e y se comunicam por parâmetros sendo que um deles é um flag que controla o comportamento de um dos módulos
3) Fundamentos (Princípios) Acoplamento acoplamento por carimbo ``stamp'': x e
y se comunicam por parâmetros, sendo um deles, uma estrutura de dados
acoplamento por dados: x e y se comunicam por parâmetros
sem acoplamento: não existe dependência
3. Tipos de MódulosQuanto ao tempo de incorporação macro – incluído em tempo de
compilação subrotina ou procedimento –
geração da seqüência de chamadas pelo compilador e posterior ligação.
ligação dinâmica – em tempo de execução.
3. Tipos de Módulos
Quanto aos mecanismos de ativação referência – chamada de sub-
programa interrupção – programa em
execução é interrompido para execução de outro módulo
3. Tipos de Módulos
Quanto ao padrão de execução módulos convencionais – um ponto
de entrada e um de saída, execução sequencial e completa
módulos reentrantes – não possui dados locais, mais de um ponto de entrada, usado simultaneamente por mais de uma tarefa (compartilhados)
3. Tipos de Módulos
Quanto ao relacionamento com outros módulos
módulo sequencial – referenciados e executados sem interrupção
módulo incremental (corotinas) – pode ser interrompido antes do seu término e posteriormente reiniciado
3. Tipos de Módulos
Quanto ao relacionamento com outros módulos
módulo paralelo (conrotinas) – executados simultaneamente com outros módulos em ambientes concorrentes
4) Principais Atividades Projeto da Arquitetura
do sistema do controle dos módulos
Projeto dos Dados Projeto dos Procedimentos Projeto da Interface com outros
Elementos do Sistema Projeto da Interface com o Usuário
5) Passos Projeto Geral ou Preliminar:
fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos
Projeto Detalhado: refinamento visando à codificação e especificação dos programas
6) Modelos de Projeto GeralOs modelos de projeto geral devem: especificar a decomposição do sistema
em sub-sistemas (modelo da arquitetura do sistema)
mostrar o relacionamento entre os sub-sistemas (modelo de controle do sistema)
decompor os sub-sistemas em módulos (modelo da arquitetura dos módulos)
7) Modelo da Arquitetura do Sistema Descreve o sistema como um
conjunto de sub-sistemas que fornecem um conjunto de serviços específicos.
Modelos que descrevem como eles compartilham dados, como eles estão distribuídos e como é a interface entre eles.
7) Modelo da Arquitetura do Sistema –Modelo Centralizado Supõe a existência de uma base
de dados central à qual todos os subsistemas têm acesso
7) Modelo da Arquitetura do Sistema –Modelo Centralizado
7) Modelo da Arquitetura do Sistema –Modelo Distribuído Cada sub-sistema mantém sua própria
base de dados Dados são trocados através dos sub-
sistemas através de mensagens mais eficiente para gde quantidade de dados maior facilidade para integrar um novo sub-
sistema permite diferentes políticas de backup,
recuperação, etc
7) Modelo da Arquitetura do Sistema –Modelo Distribuído Problemas
distribuir informações pode provocar redundância e inconsistência
esquemas eficientes de comunicação são necessários, recuperação, etc
Modelo de arquitetura cliente-servidor: O modelo + conhecido
7) Modelo da Arquitetura do Sistema– Cliente-Servidor Mostra como se dá a distribuição dos
serviços através dos sub-sistemas Composto de:
um conjunto de servidores: oferecem serviços específicos. Ex: servidores de impressão, compilação, etc.
um conjunto de clientes: que utilizam os serviços (podem ser várias instâncias de um mesmo cliente)
uma rede de comunicação A arquitetura três-camadas: + utilizada
7) Modelo da Arquitetura do Sistema– Cliente-Servidor
7) Modelo da Arquitetura do Sistema– Cliente-Servidor
8) Modelo de Controle do Sistema
Especificam as relações de controle entre os sub-sistemas
Controle centralizado: um sub-sistema é responsável por controlar, iniciar e parar os outros sistemas
Controle baseado em eventos: Cada sub-sistema pode responder a eventos externos ou originados no próprio sistema
8) Modelo de Controle do Sistema Controle Centralizado
Exemplo1:
Exemplo2:
--------------------------------------------------------
8) Modelo de Controle do Sistema - Baseado em Eventos
8) Modelo de Controle do Sistema - Baseado em Eventos
9) Diagrama de Pacotes da UML
Um pacote é um conjunto de elementos agrupados. Esses elementos podem ser classes, diagramas, ou até mesmo outros pacotes.
9) Diagrama de Pacotes da UML
9) Diagrama de Pacotes da UML – Modelo Três Camadas
Apresentação: janelas, relatórios Aplicação: registrar vendas, autorizar
pagamentos Armazenamento: BD
1. Pode-se separar a camanda da aplicação em diferentes componentes a serem reutilizados
2. Diferentes equipes para o desenvolvimento3. Camadas distribuídas em um sistema
cliente servidor aumentam desempenho
9) Diagrama de Pacotes da UML – Modelo Três Camadas
9) Diagrama de Pacotes da UML – Camada do Domínio
9) Diagrama de Pacotes da UML – Exemplo
9) Diagrama de Pacotes da UML – Padrões para construirPadrão Domínio-Apresentação
Separados (Modelo-Visão Separados)
Problema: Separar apresentação da camada do domínio para aumentar reuso e diminuir impacto de mudanças.
Solução: As classes da apresentação não mantêm dados, apenas realizam E/S, acoplamento mínimo de objetos do domínio com janelas da apresentação.
9) Diagrama de Pacotes da UML – Padrões para construir
10) Modelo da Arquitetura dos Módulos Especifica a decomposição de cada sub-
sistema em módulos Orientados a funções: os sub-sistemas são
decompostos em módulos funcionais que recebem dados e transformam estes dados em saída (ex:diagrama hierárquico de funções)
Orientado a objetos: os sub-sistemas são decompostos em um conjunto de objetos que se comunicam para resolver o problema (ex:diagramas de interação -UML)
11) Diagrama Hierárquico de Funções - DHF É obtido a partir do DFD e representa
como os módulos (processos/bolhas) são organizados a fim de compor a solução
Também representa controle – hierarquia
11) Diagrama Hierárquico de Funções - DHF
11) Diagrama Hierárquico de Funções - DHF
11) Diagrama Hierárquico de Funções(DHF) Como construir
São três passos1. Identificar a categoria do fluxo de
informação transformação ou transação
2. Revisar DFD´s e mapeá-los para o DHF
3. Revisar o diagrama através de regras de projeto e acrescentar se necessário módulos de tratamento de erros e excessão
11) Diagrama Hierárquico de Funções(DHF) Como construir
1. Identificando o Fluxo – Fluxo de Transformação
11) Diagrama Hierárquico de Funções(DHF) Como construir1.Identificando o Fluxo – Fluxo de Transação
11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transformação
11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transformação
11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transação
11) Diagrama Hierárquico de Funções(DHF) Como construir2. Mapeamento do Fluxo de Transação
11) Diagrama Hierárquico de Funções(DHF) Como construir3. Revisar a estrutura – Regras de Projeto1. Reduzir acoplamento e aumentar coesão explosão de módulos
implosão de módulos
11) Diagrama Hierárquico de Funções(DHF) Como construir2. Minimizar estruturas com fan-in e fan-out,
aumentando fan-in à medida que a profundidade aumenta – estrutura oval
3. Manter o escopo do efeito de um módulo dentro do escopo de controle do módulo
4. Reduzir complexidade das interfaces entre os módulos
5. Evitar módulos muito restritivos – portabilidade
6. Utilizar ED as menos complexas possíveis
12) Diagramas de Interação Ilustram como objetos interagem
via mensagens e como realizam tarefas com o objetivo de cumprir as pós-condições dos contratos. Diagramas de Colaboração – grafo
ou rede Diagramas de Sequências – traços
de eventos
12) Diagramas de Interação
12) Diagramas de Interação
12.1) Diagrama de Colaboração - Notação
12.1) Diagrama de Colaboração - Notação
12.1) Diagrama de Colaboração - Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.1) Diagrama de Colaboração – Notação
12.2) Diagrama de Colaboração e Outros Modelos
12.3) Diagrama de Colaboração –Como Construir Atribuir responsabilidades: parte difícil
e importante Auxílio: uso de ``patterns'' que são
diretrizes e princípios a serem aplicados Criar um diagrama para cada operação
do sistema; para cada msg de operação do sistema, fazer um diagrama com ela sendo a msg inicial
12.3) Diagrama de Colaboração –Como Construir Se o diagrama ficar complexo, divida-o em
diagramas menores Usando responsabilidades e pós condições
dos contratos e, a descrição de caso de uso como ponto inicial, projete objetos interagindo para completar as tarefas.
Métodos: cumprem as responsabilidades.
12.3) Diagrama de Colaboração –Como Construir Responsabilidades: Contrato ou obrigação
de uma classe: saber: saber sobre os seus dados, sobre objetos
relacionados, sobre coisas que ele pode calcular ou derivar. fazer: iniciar ações entre outros objetos, controlar e
coordenar atividades em outros objetos
Aplique padrões para fazer um bom projeto e para estabelecer os métodos e operações de cada objeto.
12.4) Diagrama de Colaboração –Padrões GraspPadrões: contêm descrições de um problema
e uma solução que pode ser utilizada em diferentes contextos.
Codificam idéias e heurísticas existentes para atribuir responsabilidades a objetos.
Padrões GRASP básicos: especialista, criador, alta coesão, baixo acoplamento, controle.
12.4) Diagrama de Colaboração –Padrões Grasp1. Padrão Especialista (Expert) Solução: Atribua uma responsabilidade a
uma classe que possui a informação necessária para cumprí-la.
Problema: Quem deveria ser responsável por calcular o total-geral de uma venda? a classe Venda possui a informação para isso
12.4) Diagrama de Colaboração –Padrões Grasp
Classe Responsabilidade
Venda sabe total geral da venda
Item de Venda sabe sub-total de cada item
Especificação do Produto
sabe preço do produto
12.4) Diagrama de Colaboração –Padrões Grasp
12.4) Diagrama de Colaboração –Padrões Grasp
12.4) Diagrama de Colaboração –Padrões Grasp2. Padrão Criador (Creator) Solução: Atribua à classe B a responsa-
bilidade de criar uma instância da classe A se:
1. B agrega objetos de A 2. B contém A 3. B armazena instâncias de A 4. B usa objetos de A 5. B possui informação necessária a criação
de A (B é um especialista para criar A)
12.4) Diagrama de Colaboração –Padrões Grasp
2. Padrão Criador (Creator) Problema: Quem deveria ser
responsável por criar a instância da classe Item de Venda? classe Venda agrega muitos objetos da classe Itens de Venda
12.4) Diagrama de Colaboração –Padrões Grasp
12.4) Diagrama de Colaboração –Padrões Grasp3. Padrão Baixo Acoplamento e Padrão
Alta Coesão (Low Coupling e High Cohesion)
Solução: Atribua responsabilidades para garantir baixo acoplamento (mede a independência da classe em relação a outras) e alta coesão (medida de relacionamento entre as responsabilidades de uma classe)
12.4) Diagrama de Colaboração –Padrões GraspProblema: Para evitar que a classe seja:
1. constantemente afetada por mudanças em outras classes
2. difícil de compreeder quando isolada 3. difícil de ser reusada sem as outras classes 4. difícil de manter
que classe poderia criar uma instância da classe Pagato?
12.4) Diagrama de Colaboração –Padrões Grasp
12.4) Diagrama de Colaboração –Padrões Grasp4. Padrão Controle (Controller) Solução: Atribua responsabilidades para
lidar com mensagens de eventos do sistema a uma classe que:
1. represente o sistema como um todo 2. represente a organização 3. represente algo ativo no mundo real
envolvido na tarefa (por exemplo o papel de uma pessoa)
4. represente um controlador artificial dos eventos de sistema de um caso de uso
12.4) Diagrama de Colaboração –Padrões GraspProblema: Quem deveria ser responsável
por lidar com um evento do sistema? um controlador é um objeto de
interface responsável por gerenciar um evento do sistema, definindo métodos para operações do sistema
Quem deveria ser o controlador para eventos do sistema tais como entrarItem e Vendafim?
12.4) Diagrama de Colaboração –Padrões Grasp
12.4) Diagrama de Colaboração –Padrões Grasp4. Padrão Controle Use o mesmo controlador para todos os
eventos do sistema no mesmo caso de uso Classes do tipo janela, applet, aplicações,
documento não deveriam realizar tarefas associadas a eventos do sistema. Elas apenas recebem e delegam os eventos ao controlador
Um evento do sistema é gerado por um ator
12.4) Diagrama de Colaboração –Padrões Grasp Um controlador não deve ter muitos
atributos e nem manter informação sobre o domínio do problema
Um controlador não deve realizar muitas tarefas, apenas delegá-las
Um bom projeto deve dar vida aos objetos, atribuindo-lhes responsabilidades, até mesmo se eles forem seres inanimados
A camada de apresentação (interface com o usuário) não deve tratar eventos do sistema
12.4) Diagrama de Colaboração –Padrões Grasp5. Padrão Comando Problema: Aplicações que recebem msg de
um sistema externo (não existe interface com o usuário). Ex: sistemas de telecomunicações
Solução: definir uma classe para cada comando, com o método executar. O controlador criará uma instância da classe correspondente a msg do evento do sistema e enviará a mensagem executar à classe comando.
12.4) Diagrama de Colaboração –Padrões Grasp
12.4) Diagrama de Colaboração –Padrões Grasp
12.4) Diagrama de Colaboração Como Construir utilize as responsabilidades e pós-
condições dos contratos e use casos de usos como ponto de partida
escolha a classe que controlará o sistema, aplicar padrão controle
para cada operação existe um contrato, uma operação vai ser uma mensagem.
12.4) Diagrama de Colaboração Como Construir separação do modelo de visão: não é
responsabilidade dos objetos do domínío se comunicarem com o usuário (ignorar responsabilidades de apresentação dos dados no display, mas toda informação do domínio de objetos tem que ser mostrada)
para um objeto enviar uma msg a outro é necessário visibilidade: habilidade de um objeto ver ou fazer referência a outro objeto
12.4) Diagrama de Colaboração – Como Construir
12.5) Diagrama de Colaboração - Visibilidade Habilidade de um objeto A ver ou fazer
referência a um outro objeto B. Para A enviar uma msg para B, B deve ser visível a A. por atributo: B é um atributo de A por parâmetro: B é um parâmetro de um
método de A localmente declarada: B é um objeto local de
um método de A; uma instância local é criada, ou ele será um valor de retorno
global: B é visível globalmente; usa-se uma variável global para armazenar uma instância - pouco recomendada
12.5) Diagrama de Colaboração - Visibilidade
12.5) Diagrama de Colaboração - Visibilidade
12.6) Diagrama de Colaboração - Exemplos
12.6) Diagrama de Colaboração - Exemplos
12.6) Diagrama de Colaboração - Exemplos
12.6) Diagrama de Colaboração - Exemplos
12.6) Diagrama de Colaboração - Exemplos
12.6) Diagrama de Colaboração - Exemplos
12.7) Diagrama de Colaboração - InicializandoComo se realizam as operações iniciais da
aplicação? Cria-se um caso de uso startUp. Seu diagrama de colaboração deve ser criado por
último, representando o que acontece quando o objeto inicial do problema é criado.
Quem deveria ser o objeto inicial do sistema? classe representando toda a informação lógica do
sistema classe representando a organização usar Padrões Alta Coesão e Baixo Acoplamento
12.7) Diagrama de Colaboração - Inicializando
12.7) Diagrama de Colaboração - Inicializando
12.7) Diagrama de Colaboração - Inicializando Conectando a camada de
apresentação com a do domínio Uma operação de startUp pode ser:
uma mensagem ``create'' para o objeto inicial;
se o objeto inicial é o controlador, uma mensagem ``run'' para um objeto inicial é enviada.
12.7) Diagrama de Colaboração - Inicializando
Se uma interface do usuário estiver envolvida ela é responsável por iniciar a criação do objeto inicial e outros associados.
Objetos da camada de apresentação não devem ter responsabilidades lógicas. Das nossas escolhas resultarão extensibilidade, claridade e manutenibilidade
12.7) Diagrama de Colaboração - Inicializando
13) Diagrama de Classes Modelo Conceitual Estendido
acréscimo de métodos, tipos dos atributos, visibilidade e navegabilidade, inclui a visão de projeto além da
visão de domínio
13) Diagrama de Classes – Como construir identificar todas as classes participantes
da solução através dos diagramas de colaboração
desenhar o diagrama copiar os atributos adicionar os métodos dos diagramas de
interação adicionar tipos de atributos, parâmetro
e retornos de métodos.
13) Diagrama de Classes – Como construir adicionar as associações necessárias a
visibilidade adicionar navegabilidade que indica a
direção de visibilidade por atributo adicionar setas pontilhadas indicando
visibilidade que não é por atributo Métodos ``create'' e de acessos aos
atributos podem ser omitidos. Os tipos podem ou não ser mostrados;
classes podem ser detalhadas ao máximo
13) Diagrama de Classes – Exemplos
13) Diagrama de Classes – Exemplos
13) Diagrama de Classes – Exemplos
14) Modelos de Projeto Detalhado O projeto detalhado concentra-se no
aprimoramento ou refinamento Gera representações/especificações das
estruturas de dados e representações algorítimicas
Utiliza ferramentas Gráficas : fluxogramas, cartas NS, diagramas de ação Tabulares : tabelas de decisão. Linguagens : pseudocódigo PDL (“Program Design
Language“)
14) Ferramentas de Projeto Detalhado - Fluxograma
Proc 1
Proc 2
cond
Parteelse
Partethen
cond Proc
F
V
sequência ifthenelse (condição) dowhile (repetição)
processamento controle condição
processamento controle condição
14) Ferramentas de Projeto Detalhado - Fluxograma
. . .
C1
C2
Cn
Proc1
Proc2
Proc n
Proc
CONDF
V
CASE (Seleção)
REPEAT UNTIL (Repetição)
14) Ferramentas de Projeto Detalhado – Fluxograma Ex.
F V
F V
1° Proc.
ELSE THEN
ELSETHEN
V
Próximo Proc.
Proc. ... 2 saídas
14) Ferramentas de Projeto Detalhado – Fluxograma• Fácil de entender e projetar;
• Problema : existência de “jump”, permite a violação dos princípios de programação estruturada.
14) Ferramentas de Projeto Detalhado – Cartas NS
sequência ifthenelse dowhile repeatuntil
Proc1
Proc2...
F Cond V
Parte ELSE
ParteTHEN
COND
PROCCOND
PROC
14) Ferramentas de Projeto Detalhado – Cartas NS
case (seleção) repetição infinita delimitação
CondValor Valor . . . Valor
proc1 proc2 Proc n. . . PROC
DO FOREVER
PROC
BEGIN
END
14) Ferramentas de Projeto Detalhado – Cartas NS
a bx1F
Case xi, i = 2,3,4 fx2 x3 x4
x5
c d e
g
h
i
x7
x6
x8j
V
V
14) Ferramentas de Projeto Detalhado – Cartas NS• Vantagens Cartaz NS :
escopo da iteração e do ifthenelse é bem definido e visível. transferências arbitrárias são impossíveis. escopo das variáveis é obvio. estruturas completas podem caber dentro de um programa. codificação é direta. pode servir como um guia para testes (ramos testados). serve como documentação.
• Desvantagens : problemas de espaço e estruturas rígidas.
14) Ferramentas de Projeto Detalhado Tabelas de Decisão
IF
ANDANDAND
THENAND
Condições
Ações
Regra dedecisão
Canhotos\Entradas RD1 RD2 RD3 RD4C1C2C3C4A1A2
14) Ferramentas de Projeto Detalhado Tabelas de DecisãoEx.: Tabela de linhas de Entrada Limitada
Condições : “S” a condição deve ser satisfeita
“N” a condição não deve ser satisfeita “ ” a condição é irrelevante
Ações : “X” a ação correspondente deve ser executada
“ “ a ação correspondente deve ser ignorada
14) Ferramentas de Projeto Detalhado Tabelas de Decisão
Rd1 RD2 RD3 RD4Limite de Crédito Satisfatório 5 N N NCrédito na Praça Favorável - S N NLiberação Especial Aprovada - - S NAprovar Pedido x x x -Rejeitar Pedido - - - x
14) Ferramentas de Projeto Detalhado Tabelas de DecisãoAs tabelas podem ser facilmente
automatizadas Facilidade para reduzir redundâncias; Verificar dependências e contradições. Não mostra laços. Não existe correspondência direta entre
tabela e algoritmo.
14) Ferramentas de Projeto Detalhado - Pseudocódigo• Linguagem natural + sintaxe de linguagens de
programação.• Palavras chaves para estruturação, declaração
de dados e modularização.• Sintaxe livre para descrever processamento.
Podese declarar dados e interfaces entre módulos.
Tradução para o programa é direta. Exitem muitas ferramentas disponíveis.
Pode ser ambíguo.
14) Ferramentas de Projeto Detalhado – ComparaçãoPara comparação, utilizar:
• possibilidades de representar modularidade;• simplicidade; • facilidade de edição; • facilidade de automação; • manutenção; • representação de dados;• conversão para código; • testabilidade e lógica.