A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Metodologia Metodologia de engenharia de software - processo para a produção organizada de software, que usa uma colecção de técnicas e de notações pré-definidas.

Apresentações semelhantes


Apresentação em tema: "Metodologia Metodologia de engenharia de software - processo para a produção organizada de software, que usa uma colecção de técnicas e de notações pré-definidas."— Transcrição da apresentação:

0 Modelação e projecto orientados por objectos
Sumário • Conceitos de modelação • Metodologia de projecto • Implementação • análise • projecto de sistema • projecto de objectos

1 Metodologia Metodologia de engenharia de software - processo para a produção organizada de software, que usa uma colecção de técnicas e de notações pré-definidas. Conceitos e notações OMT — já vistos Ciclo de vida do software formulação do problema análise - compreensão e modelação da aplicação e do domínio projecto - construção da solução sistema - organização de subsistemas; concorrência objectos - algoritmos; definição da implementação implementação teste manutenção aperfeiçoamento desenvolvimento operação

2 Características salientes
suporte para prototipagem rápida — desenvolvimento incremental decomposição de funções para um protótipo pode não servir para a implementação completa; mas a decomposição em objectos sim ciclo de vida — desenvolvimento sequencial deslocação do esforço de desenvolvimento para a análise — reaproveitamento em novas implementações e alterações ênfase na estrutura de dados, antes da funcionalidade — objecto como conceito unificador, em torno do qual se organizm as funções, associações e eventos processo de desenvolvimento sem descontinuidades — sempre a mesma notação; refinamentos sucessivos processo iterativo — pequenos passos validáveis

3 Análise Análise - obter um modelo do sistema real preciso, conciso, compreensível e correcto, clarificando os requisitos e evitando decisões de implementação. compreender o problema validar com o cliente acomodar o projecto e a implementação Utilizadores Gera pedidos Programadores Gestores a formulação inicial é muitas vezes vaga, incompleta e informal no fim da análise, o modelo tripartido deve ser uma clara especificação do que deve ser feito, sem prescrever o modo de o fazer Especificação do problema Entrevistas com utilizadores Constrói modelos Conhecimento do domínio Experiência do mundo real Modelo de objectos Modelo dinâmico Modelo funcional

4 Especificação Requisitos âmbito do problema o que é necessário
contexto da aplicação pressupostos necessidades de desempenho especificação inicial — ponto de partida, não um documento acabado é natural que seja ambígua, incompleta, inconsistente, errada, ignorando as reais necessidades do cliente, ou irrealista — uma vez que foi feita sem uma análise completa fazer exactamente o que o cliente pede, se não for isso que ele necessita, não evita queixas

5 Exemplo do Multibanco Balcão ATM Conta ATM Computador central
de banco Conta ATM Conta Computador de banco Conta Projecte o software de suporte a uma rede bancária computorizada, com caixas humanos e caixas automáticas (ATM), para ser partilhado pelos bancos de um consórcio. Cada banco tem o seu próprio computador para manter as suas contas e processar as transacções sobre elas.Os balcões pertencem a bancos individuais e comunicam directamente com os respectivos computadores. Os caixas humanos introduzem dados de contas e de transacções. As caixas automáticas comunicam com um computador central que acerta as transacções com o banco correspondente. Uma caixa automática aceita um cartão de débito, interage com o utilizador, comunica com o sistema central para proceder à transacção, entrega dinheiro e imprime recibos. O sistema necessita de um conveniente registo e de esquemas de segurança. O sistema deve lidar correctamente com acessos concorrentes à mesma conta. Os bancos fornecem o software para os seus computadores. Pretende-se projectar o software para as caixas automáticas e para a rede. O custo do sistema partilhado será repartido pelos bancos de acordo com o número de clientes com cartões de débito.

6 Modelação de objectos Passos identificar objectos e classes
preparar um dicionário de dados identificar associações entre objectos identificar atributos de objectos e de ligações organizar e simplificar as classes usando herança verificar os caminhos de acesso para perguntas previsíveis iterar e refinar o modelo agrupar as classes em módulos é essencial a organização de alto nível do sistema em classes e mais secundário o refinamento em hierarquias de generalização organizar a herança só depois de especificar os atributos das classes, para evitar preconceitos as operações são adicionadas posteriormente, como subproduto da construção dos modelos dinâmico e funcional

7 Selecção de classes Classes - identificar os substantivos da descrição do problema e do conhecimento do domínio. Eliminar classes redundantes classes irrelevantes classes vagas atributos operações papéis construções da implementação

8 Selecção de associações
Associações - identificar os verbos e frases verbais da descrição do problema. Eliminar associações entre classes eliminadas associações irrelevantes ou de implementação acções associações ternárias associações derivadas Especificar associações mal designadas nomes dos papéis associações qualificadas multiplicidade associações que faltem

9 Selecção de atributos Atributos - substantivos com determinante e adjectivos da descrição do problema e outros que vão surgindo ao longo do processo. Eliminar objectos qualificadores em contexto nomes identificadores atributos de ligações valores internos detalhe fino atributos dissonantes

10 Exemplo de modelo de objectos
Transacção Posto Constituída por dia-hora Introduzida em Transacção na caixa Transacção remota ATM Balcão dinheiro existente entregue Introduzida por Actualização Possui Possui Caixa montante tipo Iniciada código de posto código de posto nome Autorização Consórcio Banco Emprega código de empregado password limite código de banco nome código de cartão Emite Tem código de conta Cartão código de banco código de cartão número de série Cliente Conta nome morada balanço limite crédito tipo Detém

11 Modelação dinâmica Passos
preparar guiões de sequências de interacção típicas identificar eventos entre objectos preparar um traço de eventos para cada guião contruir um diagrama de estados emparelhar eventos entre objectos para verificar a consistência a execução de algoritmos não é relevante durante a análise, se não existirem manifestações externas; é uma questão de implementação correcção lógica depende das sequências das interacções e não dos seus instantes exactos (excepto nos sistemas de tempo real)

12 Modelação funcional Passos identificar os valores de entrada e saída
construir os diagramas de fluxo de dados, mostrando as dependências funcionais descrever as funções identificar as restrições especificar critérios de optimização as funções são expressas de várias formas, incluindo linguagem natural, equações matemáticas e pseudo-código os processos num DFD correspondem a actividades ou acções nos diagramas de estados das classes os fluxos num DFD correspondem a objectos ou valores de atributos num digrama de objectos é preferível construir o modelo funcional depois dos modelos dinâmico e de objectos

13 Adição das operações OMT põe menos ênfase na definição das operações do que as metodologias OO baseadas em programação: a lista das operações úteis é aberta classes de operações comuns em LPOO perguntas sobre atributos ou associações no modelo de objectos acesso a atributos (assume-se que todos estão disponíveis) e navegação através de pseudo-atributos (papéis das associações) [ATM.quantia, conta.banco] não representar no modelo de objectos eventos no modelo dinâmico tratador de eventos ou métodos explícitos acções e actividades no estado indicar as interessantes no modelo de objectos [verificar código do banco em Consórcio, verificar password em Banco] funções no modelo funcional indicar no modelo de objectos, directamente ou após reestruturação

14 Simplificação de operações
lista de compras — conjunto de operações sugerido pelo comportamento das classes no mundo real e que não são especificamente exigidas pela aplicação; dá maior versatilidade e autonomia às classes; permite responder a algumas questões não previstas — perspectiva abrangente de construção debibliotecas de classes [conta :: autoriza-cartão(autorização de cartão)] simplificar — factorizar operações similares; criar superclasses para albergar as operações genéricas iterar a análise o número de vezes necessário para obter um modelo coerente sem omissões e sem elementos supérfluos estes modelos são um bom meio para a validação por parte de peritos do domínio não há uma fronteira definida entre a análise e o projecto — o que muda é a atitude: da compreensão do problema passa-se para a construção da solução

15 Projecto de sistema Projecto de sistema - é a estratégia de alto nível para resolver o problema e construir a solução: define a arquitectura do sistema. Passos organizar o sistema em subsistemas identificar a concorrência inerente ao problema atribuir subsistemas a processadores e a tarefas escolher uma forma de gerir os depósitos de dados lidar com os recursos globais escolher a implementação do controlo tratar as condições fronteira definir critérios de prioridade para os compromissos

16 Subsistemas subsistema - pacote de classes, associações, operações, eventos e restrições interrelacionados e com uma interface pequena e bem definida com os outros subsistemas a decomposição em subsistemas pode ter vários níveis, sendo o inferior constituído por módulos critérios: funcionalidade comum mesma localização física execução no mesmo tipo de hardware subsistema identificado pelos serviços, grupos de funções com um propósito comum relacionamento entre dois subsistemas cliente-fornecedor (comunicação da iniciativa do cliente — conhece interface do fornecedor) par-a-par (cada um pode iniciar comunicação — tem que conhecer a interface do outro; mais complexo) topologias descritas por DFDs (pipeline, estrela, etc.)

17 Decomposição em subsistemas
organização em camadas de máquinas virtuais ou em partições verticais por serviço exemplo típico: pacote da aplicação gráficos de janela controlo de diálogo com utilizador pacote de simulação gráficos de écrã gráficos ao pixel sistema operativo hardware do computador

18 Concorrência no modelo da análise, no mundo real e no hardware os objectos são concorrentes objectos com actividade mutuamente exclusiva podem ser agrupados numa mesma tarefa dois objectos são inerentemente concorrentes se podem receber eventos simultanemente sem interagirem hardware separado monoprocessador com multitarefa um fio de controlo (thread) é um caminho através de um conjunto de diagramas de estado em que apenas um objecto se encontra activo em cada instante (implementado por uma tarefa) atribuição de subsistemas a processadores e tarefas estimar necessidades de desempenho e de recursos escolher implementações de hardware ou software atribuir subsistemas, minimizando a comunicação inter-processador determinar a conectividade das unidades físicas dos subsistemas (comunicação síncrona, assíncrona, bloqueante)

19 Depósitos de dados candidatos naturais a subsistemas
dados transitórios em estruturas de dados em RAM; persistência em ficheiros ou em BD persistência ortogonal e BDOO vantagens de usar uma BD muitos serviços de infraestrutura (recuperação, partilha, distribuição, integridade) interface comum para todas as aplicações linguagem de acesso standard (SQL) portabilidade desvantagens sobrecarga de desempenho funcionalidade insuficiente para aplicações avançadas desadaptação de impedância com as linguagens de programação

20 Controlo acesso a recursos globais protocolo de acesso
objecto guardião bloqueio (lock) modelo de controlo da execução sequencial, guiado pelos procedimentos sequencial, guiado por eventos concorrente paradigma da programação em lógica condições fronteira inicialização terminação falha

21 Arquitecturas vulgares
Transformação por lotes (batch) — a transformação é executada uma vez para todo o conjunto de entrada Transformação contínua (pipeline) — a transformação é executada continuamente à medida que a entrada evolui Interface interactivo — sistema reactivo dominado pelas interacções externa Simulação dinâmica — simula objectos a evoluirem no mundo real Sistema de tempo-real — dominado pelas restrições de tempo de resposta Gestor de transacções — sistema dedicado a memorizar e disponibilizar dados, incluindo acesso concorrente

22 Arquitectura do sistema Multibanco
Computadores dos bancos Computador do consórcio Postos ATM Caixa Consórcio Balcão ATM linhas telefónicas Base de dados Cartão código de posto Utilizador Conta linhas telefónicas interface utilizador código de banco Cliente Autorização Transacção Transacção Transacção

23 Projecto de objectos Projecto de objectos - determina as definições completas das classes e associações usadas na implementação e as interfaces e os algoritmos dos métodos que implementam as operações. ênfase em conceitos computacionais e não nos do domínio da aplicação objectos da análise formam o esqueleto mas novos objectos são adicionados para construir a solução, guardar resultados intermédios, representar estruturas de dados Passos combinar os três modelos para obter as operações nas classes projectar os algoritmos optimizar os caminhos de acesso aos dados implementar o controlo das interacções externas ajustar a estrutura de classes para aumentar a herança projectar as associações determinar as representações dos objectos empacotar as classes e as associações em módulos

24 Algoritmos nos diagramas de estados, as acções executadas numa transição dependem do evento e do estado do objecto — podem corresponder a operações diferentes uma acção ou actividade iniciada por uma transição do diagrama de estados pode ser expandida num DFD completo, cujos processos representam o corpo da operação os algoritmos podem ser construídos descendentemente, por refinamentos sucessivos até se atingir o nível da implementação directa programador deve escolher algoritmos que minimizem o custo de implementar as operações seleccionar as estruturas de dados apropriadas definir as novas classes internas e operações necessárias atribuir a responsabilidade das operações às classes optimização adicionar associações redundantes para minimizar custo de acesso rearranjar a computação memorizar atributos derivados de cálculo custoso

25 Implementação do controlo
três métodos de implementar o modelo dinâmico utilizar a localização no programa para guardar o estado (sistemas guiados por procedimentos) implementar directamente um mecanismo de máquina de estados (sistemas guiados por eventos) usar tarefas concorrentes criar uma classe genérica para máquina de estados um interface de utilizador pode recorrer a essa classe e a stubs (funções só com interface e um mínimo de corpo) para criar um protótipo a partir de uma tabela de estados e de eventos

26 Implementação das associações
associações são consideradas bidireccionais (mesmo nos protótipos) até à implementação associações unidireccionais apontador - multiplicidade 1: simples - multiplicidade muitos: conjunto - ordenada: lista - qualificada: dicionário (hash) associações bidireccionais implementar como unidireccional e fazer pesquisa no sentido inverso implementar como duplo unidireccional; manter a consistência implementar a associação como objecto distinto que é um conjunto de pares ou um duplo dicionário (para aumentar a eficiência) Trabalha Pessoa Empresa (Pessoa) (Empresa) empregador (Pessoa) (Empresa) empregados

27 Associação bidireccionais
Trabalha Pessoa Empresa apontadores associação como classe (Pessoa) (Empresa) (Pessoa) Trabalha empregador empregados (Pessoa) (Empresa) (Conjunto) (Pessoa) (Pessoa) (Empresa) (Pessoa) (Pessoa) útil para estender classes pré-definidas não modificáveis suporta atributos de ligação com triplos representa associações qualificadas

28 Documentos da metodologia
A Documento da Análise A0 Formulação do problema A1 Modelo de objectos = diagrama de objectos + dicionário de dados A2 Modelo dinâmico = diagramas de estado + diagrama global de fluxo de eventos A3 Modelo funcional = diagramas de fluxo de dados + restrições PS Documento do Projecto de Sistema estrutura da arquitectura básica do sistema e decisões estratégicas de alto nível P Documento do Projecto = P1 modelo de objectos detalhado + P2 modelo dinâmico detalhado + P3 modelo funcional detalhado


Carregar ppt "Metodologia Metodologia de engenharia de software - processo para a produção organizada de software, que usa uma colecção de técnicas e de notações pré-definidas."

Apresentações semelhantes


Anúncios Google