Análise e Projeto Orientados a Objeto

Objetivos

• Comparar e contrastar Análise e Projeto
• Definir Análise e Projeto Orientados a Objeto

O que vamos fazer na disciplina?

• Saber uma linguagem de programação orientada a objeto (OO) não é suficiente para criar sistemas OO
  • Tem que saber Análise e Projeto OO (APOO)
  • Isto é, Análise e Projeto usando uma perspectiva de objetos
• Usaremos um estudo de caso para concretizar a discussão
• Usaremos a linguagem UML (Unified Modeling Language) para criar modelos (de análise e de projeto)
  • Um modelo é uma representação abstrata dos aspectos essenciais de um sistema
  • O que é "essencial" depende do momento da modelagem
  • A UML usa uma representação principalmente gráfica para representar os modelos
  • UML é muito popular hoje em dia para modelar sistemas
• Usaremos Design Patterns (padrões de projeto) para mostrar soluções abstratas para problemas que surgem frequentemente durante o projeto de sistemas OO
  • Os patterns tratarão principalmente de:
    • Como atribuir responsabilidades a objetos (uma das atividades mais difícil no desenvolvimento de sistemas OO)
    • Como separar o que muda do que é constante numa determinada situação, com o objetivo de ganhar flexibilidade
      • Para evitar "o efeito gelatina"
• Explicaremos e seguiremos um processo de desenvolvimento que mostra claramente quais são as etapas a seguir para produzir software de qualidade
  • Veremos também quais artefatos devem ser produzidos na várias fases e etapas do processo

O que é Análise e Projeto?

• Diferenças entre análise e projeto: tem mais do que uma definição empregada
  • Primeira alternativa:
    • A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema (o que deve ser feito). É uma atividade de investigação.
    • O projeto modela a solução e consiste das atividades de criação (como pode ser feito)

• Segunda alternativa:
  • A análise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar
  • O projeto inclui as atividades que resultam em informação que interessa apenas ao programador
  • Com essa definição, a análise invade um pouco o "lado da solução", pois o cliente deve discutir alguns tipos de interações que ocorrerão na interface do usuário, etc.

• Observe portanto que não definição binária que isole "análise" de "projeto"
• Nesta disciplina, adotaremos a segunda alternativa, pois queremos associar as palavras "análise" e "projeto" aos artefatos (deliverables) entregues nos final de cada fase
  • Um modelo de análise deve ser aprovado pelo cliente e pode incluir alguma (pequena) discussão da solução, principalmente no que diz respeito à interface com usuário, etc.
• Apesar do nome da disciplina, vamos ver também as fases de requisitos, implementação e testes
  • A obtenção de requisitos é frequentemente incluída na fase de análise ("análise de requisitos")

O que é Análise e Projeto Orientados a Objeto (APOO)?

• A perspectiva empregada é de objetos (coisas, conceitos ou entidades)

• Durante a Análise OO, a ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema
  • Por exemplo, num sistema de informação para uma biblioteca, alguns dos conceitos são Livro, Biblioteca, Usuário.
  • Tais objetos podem ter atributos e responsabilidades
• Durante o projeto orientado a objeto, a ênfase está em achar objetos lógicos de software que poderão ser eventualmente implementados usando uma linguagem de programação OO
  • Tais objetos pode ter atributos e métodos
• Durante a construção (programação OO), os objetos do projeto são implementados e testados

APOO versus AP Orientados a Funções (APOF)

• Com ambas as técnicas, usa-se decomposição (chamado modularização em APOF) para lidar com a complexidade
• A APOF (também chamados de Análise e Projeto Estruturados), a decomposição é por função ou processo

Por que queremos Orientação a Objeto? Quais são as vantagens?

• As abstrações podem corresponder às coisas do domínio do problema
  • O nível é mais natural
  • É mais fácil comunicar-se com o usuário ou domain expert na linguagem dele
• Os mesmos objetos existem em todas as fases e uma notação única (objetos) facilita portanto a integração entre fases de desenvolvimento (passar de uma fase para a outra)
  • Fases posteriores adicionam novos objetos mas os objetos do domínio do problema permanecem: são estáveis
  • Isso ajuda o rastreamento de decisões de projeto e implementação
• É mais fácil entender o domínio do problema quando esta é quebrado em pedaços: gerenciamento da complexidade através da modularização
• O mesmo pode ser dito no domínio do computador (projetando e programando com objetos)
• A abstração controla a complexidade (escondendo algo através da separação da interface e da implementação)
• A encapsulação facilita as mudanças (através do isolamento)
• A hierarquia (grafo de herança) permite uma melhor reutilização
• Hierarquia promove a flexibilidade de fazer mudanças de forma localizada
  • Exemplo: novos trechos de programas podem usar uma sub-classe nova e código antigo continua usando a superclasse e não toma conhecimento das mudanças
  • Porém, há problemas de acoplamento com herança que veremos em outro capítulo
• A reutilização de pedaços é mais difícil usando paradigmas anteriores (modularização via funções) porque não posso usar coisas pré-existentes tão facilmente
  • Com objetos, posso dizer: "me dê dois daqueles" porque objetos têm estado
  • Não posso fazer isso com funções porque elas não encapsulam estado

intro-1 programa próxima