©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/38 Análise e Projeto de Sistemas...

CIn-UFPECIn-UFPE 11/38/38©2003, Alexandre Vasconcelos & Augusto Sampaio©2003, Alexandre Vasconcelos & Augusto Sampaio

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

Introdução à Análise e ao Projeto de Introdução à Análise e ao Projeto de SoftwareSoftware


Objetivos da AulaObjetivos da Aula

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


Análise x ProjetoAnálise x Projeto

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

Durante o Projeto: detalhamos a Análise de modo a encontrar uma solução

computacional que satisfaça os requisitos do software estruturamos COMO o sistema será implementado

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


Análise x ProjetoAnálise x Projeto

No conceito de MDA (Model Driven Architecture) da OMG (Object Management Group) ... Análise corresponde aos modelos independentes de plataforma

(PIM – Platform Independent Model) No projeto, os modelos podem estar vinculados a uma

tecnologia particular (PSM – Platform Specific Model)


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

Processo criativo Baseado no aprendizado

Prática

Experiência, exemplos

Padrões

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


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]


Principais Fases do Processo de ProjetoPrincipais Fases do Processo de Projeto

Analisar o problema Olhar para o problema de 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


Refinamento de ProjetoRefinamento de Projeto

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

Informal Informaldesign

Moreformaldesign

Finisheddesign

designoutline


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



Projeto de arquitetura: Identifica subsistemas e outros elementos de projeto

Especificação abstrata: Para cada subsistema (e outros elementos de projeto) é produzida uma especificação abstrata de suas funções e das restrições dentro das quais deve operar.

Projeto de interface: Especifica as interfaces entre subsistemas



Projeto de componentes: Transforma (possivelmente decompondo) subsistemas 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 descrever os elementos de projeto e os relacionamentos entre estes.

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 (elementos de projeto)

Classes, Tipos, processos, subsistemas,

funções, ...

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

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

Mas padronização é fundamental ...


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

Modelo de fluxo de dados: transformação de dados Modelo estrutural: elementos 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 oferecem mecanismos de garantia de consistência entre os diversos modelos gerados

Uma alternativa é complementar estes métodos com uma notação mais precisa para descrever comportamento Exemplo: UML + OCL


Estratégias de decomposiçãoEstratégias de decomposiçãoProjeto 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 é

inteiramente top-down.

Os projetistas reutilizam experiência (e

componentes)

No processo, ocorre brainstorm nos dois sentidos


Estratégias de DecomposiçãoEstratégias de DecomposiçãoFuncional x DadosFuncional x Dados

Decomposição Funcional Decomposição do sistema em componentes

funcionais O estado do sistema é centralizado e

compartilhado entre as funções Experiência mostrou inadequação para

estruturação de modelos de análise e projeto (as regras de negócio mudam constantemente)

Entretanto, útil para estruturar requisitos, planejar e gerenciar projetos


Estratégias de DecomposiçãoEstratégias de DecomposiçãoFuncional x DadosFuncional x Dados

Decomposição Baseada em Dados O sistema é visto como uma coleção de entidades

que interagem (ou objetos, no paradigma OO) 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 reusadas no projeto Mostrou-se adequada como mecanismo de

estruturação (estabilidade de dados com relação a funções) de modelos de análise e projeto


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


Top-down x Bottom-up e Top-down x Bottom-up e Funcional X DadosFuncional X Dados

Estratégias ortogonais (independentes) Por exemplo, uma estratégia Top-Down baseada

em dados decompõe classes usando o mecanismo de herança

Uma estratégia Bottom-Up baseada em dados usaria generalização

Uma estratégia Top-Down funcional inicia com a visão funcional do sistema e decompõe em subunidades

Uma estratégia Bottom-Up funcional reutilizaria bibliotecas de funções no projeto de funções mais complexas


Atributos de Qualidade de ProjetoAtributos de Qualidade de Projeto

A qualidade é uma propriedade relativa a 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 principalmente a facilidades de evolução e manutenção de um projeto


O Atributo Coesão O Atributo Coesão

Medida da proximidade das partes (elementos) 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á facilmentelocalizada


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 a estrutura de uma classe, a superclasse e a

própria classe precisam ser examinadas


Medida da intensidade das interconexões entre componentes do sistema

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

tendem a não afetar outros componentes

O Atributo AcoplamentoO Atributo Acoplamento


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, potencialmente, fracamente acoplados Geralmente não compartilham estado A comunicação é feita através de passagem de mensagens

Entretanto... uma classe está acoplada a sua superclasse (mudanças nos

atributos ou operações se propagam a todas as subclasses) Relacionamentos cíclicos (em particular, bidirecionais) também

geram forte acoplamento

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


Relacionado a várias características do componente Acoplamento e Coesão. Cada componente modela

(completamente) uma única abstração?

Nomes. São usados nomes sugestivos?

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

Complexidade. Algoritmos complexos são utilizados?

Padrões. Soluções conhecidas são utilizadas?

O Atributo EntendimentoO Atributo Entendimento


Medida da facilidade de mudança nos componentes Alguns fatores relevantes

Componentes fracamente acoplados Componentes fortemente coesos Boa documentação

O Atributo AdaptabilidadeO Atributo Adaptabilidade


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 Performance - tempo de resposta, tempo total de execução Eficiência - uso eficiente do dispositivo de armazenamento

e do hardware Portabilidade - funcionar em novas plataformas Segurança Disponibilidade - disponível quando requerido Robustez Generalidade Usabilidade Reusabilidade


Compromissos de ProjetoCompromissos de Projeto

É impossível alcançar todos os objetivos Performance X Portabilidade Performance X Generalidade


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 Os resultados obtidos a partir do sistema implementado

devem acontecer na data apropriada Integração com outros sistemas Habilidades

da equipe de projeto e usuários Padrões

internos e externos


Medindo a Eficiência do ProjetoMedindo a Eficiência do Projeto

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

tempo de resposta Portabilidade

plataformas


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 re-aprender o sistema depois de um período sem

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

Medindo a Eficiência do ProjetoMedindo a Eficiência do Projeto


Projeto é um processo de engenharia (modelagem), mas exige criatividade

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 (estado centralizado) Importante para definir escopo, planejar, gerenciar e testar

Orientação a objetos considera o sistema como uma coleção de objetos (estado descentralizado) Importante na modelagem estrutural e de dados

Projetistas devem procurar produzir sistemas Fortemente coesos Fracamente acoplados

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/38 Análise e Projeto de Sistemas...

Documents

Transcript of ©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/38 Análise e Projeto de Sistemas...