CIn-UFPE1 Análise e Projeto de Sistemas Introdução ao Projeto de Software.

CIn-UFPECIn-UFPE 11

Análise e Projeto de SistemasAnálise e Projeto de Sistemas

Introdução ao Projeto de SoftwareIntrodução ao Projeto de Software

CIn-UFPECIn-UFPE 22

Projeto de SoftwareProjeto de Software

Derivando uma solução que satisfaz os requisitos do software

CIn-UFPECIn-UFPE 33

ObjetivosObjetivos

Discutir as diferenças entre Análise e Projeto

Introduzir o processo de projeto de software

Descrever os diferentes estágios deste processo

Discutir as estratégias de projeto de software funcional e

orientada a objeto

Discutir alguns atributos de qualidade de projeto de software

CIn-UFPECIn-UFPE 44

Análise x ProjetoAnálise x Projeto

Na Análise, investigamos o problema e descobrimos O QUE precisa estar no novo sistema

Durante o Projeto determinamos COMO isto será feito

Durante o projeto planejamos a estrutura do sistema que será implementado

O projeto oferece uma ponte entre a Análise e a Implementação

CIn-UFPECIn-UFPE 55

Características do Projeto de SoftwareCaracterísticas do Projeto de Software

Processo criativo Baseado no aprendizado

Prática

Experiência

Estudo de Exemplos

Deriva uma solução que satisfaz os requisitos de software

Influenciado pela implementação computacional Deve incluir detalhes (baixo nível) que foram

ignorados no modelo de análise

CIn-UFPECIn-UFPE 66

Definição de Projeto de SoftwareDefinição de Projeto de Software

“Após a análise do problema, você deve decidir a abordagem do projeto. O projeto do sistema é uma estratégia de alto nível para resolução de problemas e construções de soluções. O projeto do sistema inclui decisões sobre a organização do sistema em termos de subsistemas, a evolução de subsistemas para componentes de software e hardware, bem como as principais decisões conceituais e políticas.”[Rumbaugh]

CIn-UFPECIn-UFPE 77

Principais Estágios de ProjetoPrincipais Estágios de Projeto

Entender o problema Olhar para o problema por diferentes ângulos Descobrir os requisitos de projeto

Identificar uma ou mais soluções Avaliar possíveis soluções Escolher a mais apropriada

Descrever as abstrações da solução Usar notações gráficas ou descritivas para especificar os

componentes do projeto Repetir este processo para cada abstração identificada até o

projeto estar expresso em termos primitivos

CIn-UFPECIn-UFPE 88

Refinamento de ProjetoRefinamento de Projeto

O sistema é projetado iterativamente emdiferentes níveis de abstração

Informal Informaldesign

Moreformaldesign

Finisheddesign

designoutline

CIn-UFPECIn-UFPE 99

Fases do Processo de ProjetoFases do Processo de Projeto

Architecturaldesign

Abstractspecificatio

n

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

CIn-UFPECIn-UFPE 1010

Fases do Processo de ProjetoFases do Processo de Projeto

Projeto de arquitetura: Identifica sub-sistemas Especificação abstrata: Para cada sub-sistema, é produzida uma

especificação abstrata de suas funções e das restrições dentro das quais deve operar.

Projeto de interface: Descreve as interfaces entre sub-sistemas Projeto de componentes: Decompõe sub-sistemas em componentes

individuais para se ajustar à arquitetura Projeto de estrutura de dados: Projeta estrutura de dados para

armazenar os dados do sistema Projeto de algoritmos: Descreve os algoritmos a serem usados na

solução do problema


Notações para Descrição de ProjetoNotações para Descrição de Projeto

Notações gráficas: Usadas para mostrar os relacionamentos entre os componentes.

Linguagens de descrição de programa: Baseadas em linguagens de programação, porém com mais flexibilidade para representar conceitos abstratos.

Texto informal: Descrição em linguagem natural.


Notações Gráficas Notações Gráficas para Modelagem de Projetopara Modelagem de Projeto

Qualquer projeto pode ser modelado como um grafo

direcionado Nós: entidades

Processos

Funções

Tipos

Arestas: relacionamentos


Métodos Estruturados de Projeto Métodos Estruturados de Projeto

Características Notações para expressar o projeto Diretrizes para criar e avaliar um projeto

Exemplos Projeto Estruturado (Yourdon) JSD (Jackson Method) Booch, OMT, UML + RUP

Vantagens Suporte de Ferramentas CASE Documentação padronizada Redução de custo (treinamento, manutenção)


Tipos de Modelos nos Métodos EstruturadosTipos de Modelos nos Métodos Estruturados

Modelo de fluxo de dados: transformação de dados Modelo estrutural: componentes do sistema e suas

interações Modelo entidade-relacionamento: estrutura lógica dos dados Modelo de herança e composição de objetos, se o método for

orientado a objetos Modelos complementares: diagrama de estados,

dicionário de dados, ...


Deficiências dos Métodos EstruturadosDeficiências dos Métodos Estruturados

Existem diretrizes e não métodos no sentido matemático. Projetistas diferentes criam projetos bastante diferentes

Não ajudam muito com a parte inicial, fase criativa do projeto. Em vez disso, ajudam ao projetista a estruturar e documentar as suas idéias de projeto


Projeto Top-down x Bottom-upProjeto Top-down x Bottom-up

System level

Sub-systemlevel


Projeto Top-down x Bottom-upProjeto Top-down x Bottom-up

Na prática, o projeto de grandes sistemas nunca é

verdadeiramente top-down.

Os projetistas reutilizam experiência (e componentes)

Ex: Orientação a objetos


Principais Estratégias de ProjetoPrincipais Estratégias de Projeto

Projeto Funcional (Imperativo) Decomposição do sistema em componentes funcionais O estado do sistema é centralizado e compartilhado entre as

funções Projeto Orientado a Objetos

O sistema é visto como uma coleção de objetos que interagem O estado do sistema é descentralizado Pode existir uma considerável sobreposição entre os modelos

de análise e de projeto. Na prática muitas porções do modelo de análise podem ser

facilmente implementadas (sem alteração)


Visão Funcional de um CompiladorVisão Funcional de um Compilador

AnalyseBuild

symboltable

Scansource

Generatecode

Symboltable

Outputerrors

Sourceprogram

Tokens Tokens Syntaxtree

Objectcode

ErrorindicatorSymbols Symbols

Errormessages


Visão Orientada a Objetos de um CompiladorVisão Orientada a Objetos de um Compilador

Sourceprogram

Tokenstream

Symboltable

Syntaxtree

Grammar Errormessages

Abstractcode

Objectcode

Scan Add

Check Get

Build Print

Generate

Generate


Aspectos que requerem atenção num projeto OOAspectos que requerem atenção num projeto OO

Incluir classes para manipular a interface com o usuário a interface com outros sistemas o armazenamento de dados toda a coordenação das outras classes

Reuso Uso de Padrões de projeto Componentes comprados de fornecedores Atribuição de responsabilidades: se a decisão é errada menos

classes serão reusáveis


Estratégias de Projeto - Qual a melhor?Estratégias de Projeto - Qual a melhor?

As abordagens orientada a objeto e funcional são complementares

Bons engenheiros de software selecionam a abordagem mais apropriada para o sistema ou fase do processo em questão


Atributos de Qualidade de ProjetoAtributos de Qualidade de Projeto

A qualidade é uma propriedade indefinível que depende das prioridades específicas da organização

Características de qualidade são igualmente aplicáveis a projetos orientados a objeto ou a função

Os atributos discutidos aqui estão relacionados com a manutenção de um projeto


Coesão Coesão

Medida da proximidade das partes de um sub-componente

Um componente deve implementar uma única entidade lógica ou função

ImportânciaQuando uma mudança tiver que ser feita, ela serálocalizada


Coesão em Orientação a ObjetosCoesão em Orientação a Objetos

Herança de atributos de uma superclasse enfraquece a coesão Para entender um componente, a superclasse e também o

componente precisam ser examinados


Medida da força das interconexões entre componentes do sistema

Importância Baixo acoplamento implica que mudanças em um componente

dificilmente afetarão outros componentes Cuidado com variáveis compartilhadas!

AcoplamentoAcoplamento


Acoplamento ForteAcoplamento Forte

Module A Module B

Module C Module D

Shared dataarea


Acoplamento FracoAcoplamento Fraco

Module A

A’s data

Module B

B’s data

Module D

D’s data

Module C

C’s data


Sistemas orientados a objeto são fracamente acoplados Geralmente não compartilham estado A comunicação é feita através de passagem de mensagens

Uma classe está acoplada à sua superclasse Mudanças nos atributos ou operações na superclasse se

propagam a todas as subclasses.

Acoplamento em Orientação a ObjetosAcoplamento em Orientação a Objetos


Relacionado a várias características do componente Coesão. Pode um componente ser entendido isoladamente?

Nomes. São usados nomes que fazem sentido?

Documentação. O projeto está bem documentado?

Complexidade. Algoritmos complexos são utilizados?

EntendimentoEntendimento


Medida da facilidade de mudança nos componentes Fatores relevantes

Componentes fracamente acoplados Componentes fortemente coesos Boa documentação Programas legíveis

AdaptabilidadeAdaptabilidade


Herança aumenta a adaptabilidade Componentes podem ser adaptados sem mudanças através da

definição de uma subclasse que é efetivamente modificada.

Por outro lado, O aumento da profundidade da hierarquia a torna mais complexa

Adaptabilidade em Orientação a ObjetosAdaptabilidade em Orientação a Objetos


Fatores que Influenciam o ProjetoFatores que Influenciam o Projeto

Funcionalidade Eficiência - tempo de resposta, tempo total de

execução, armazenamento, hardware Portabilidade - funcionar em novas plataformas Segurança Disponibilidade - disponível quando requerido Robustez Genericidade Usabilidade Reusabilidade


Compromissos de ProjetoCompromissos de Projeto

É impossível alcançar todos os objetivos Ex: Performance X Custo

sistemas mais rápidos --> custos mais altos: é preciso definir prioridades

Usabilidade X Performance X Custo, ex. GUIs Melhor aceitação do usuário --> Maior tempo de

desenvolvimento --> Performance reduzida --> Maior custo de hardware


Compromissos de ProjetoCompromissos de Projeto Projeto acontece no contexto do mundo real Portanto, deve levar em consideração:

Investimento custos de projeto e execução

Prazos bom projeto leva mais tempo para executar e

implementar Os resultados obtidos a partir do sistema implementado

devem acontecer na data apropriada (ex: Y2K) Integração com outros sistemas Habilidades

da equipe de projeto e usuários Padrões

internos e externos


Medindo Eficiência do ProjetoMedindo Eficiência do Projeto

Sucesso deve ser mostrado em termos de objetivos mensuráveis Funcionalidade - presente ou ausente Eficiência

tempo de resposta Portabilidade

afetada pela linguagem, padrões de codificação e documentação do programa


Disponibilidade ex. Sistema funcionando 98% do tempo.

Robustez ex. 90% das falhas são recuperadas em uma hora

Usabilidade tempo para aprender a usar o sistema freqüência de erros tempo para recuperar de erros específicos tempo para reaprender o sistema depois de um período sem usá-

lo atitude e satisfação do usuário (questionário)

Medindo Eficiência do ProjetoMedindo Eficiência do Projeto


Projeto é um processo criativo

Atividades de projeto incluem Projeto de arquitetura Especificação de sistema Projeto de interface Projeto de componentes Projeto de estrutura de dados Projeto de algoritmos

Pontos PrincipaisPontos Principais


Pontos PrincipaisPontos Principais

Decomposição funcional considera o sistema como um conjunto de unidades funcionais

Orientação a objeto considera o sistema como uma coleção de objetos

Projetistas devem procurar produzir sistemas Fortemente coesos Fracamente acoplados

CIn-UFPE1 Análise e Projeto de Sistemas Introdução ao Projeto de Software.

Documents

Transcript of CIn-UFPE1 Análise e Projeto de Sistemas Introdução ao Projeto de Software.