Análise e Projeto Orientado a Objetos Aula 1.3 - Introdução à APOO Bruno Neiva Moreno Instituto Federal do Rio Grande do Norte Campus Nova Cruz bruno.moreno@ifrn.edu.br 1/18
Introduc a o Motivac a o e Princı pios Ana lise e Projeto OO Ana lise OO Projeto OO Leitura Sugerida Introduc a o Possuir la pis e re gua te faz um arquiteto? 2/18 APOO - Ana lise e Projeto Orientado a Objetos
Introdução Você pode conhecer toda a API Java, C++ ou de qualquer outra LPOO. 3/18
Introdução Mas para criar sistemas OO de alto nível, você precisa PENSAR EM OBJETOS. 4/18
Motivação Como as responsabilidades devem ser atribuídas às classes de objetos? Como os objetos devem interagir entre si? Quais classes devem fazer o que? Essas questões são muito importantes no projeto OO. 5/18
Princípios Todo projeto de software está fortemente relacionado à atividade de pré-requisitos: Análise de Requisitos A análise enfatiza a investigação do problema e dos requisitos Análise dos Requisitos Investigação dos Requisitos A atividade de análise de requisitos está presente na maioria dos processos de desenvolvimento 6/18
Princípios O projeto enfatiza uma solução conceitual que satisfaça os requisitos e não sua implementação. Projetos podem ser implementados e a implementação (e.g. código) expressa o projeto completamente realizado. Análise pode ser resumida com fazer a coisa certa, e projeto como faça certo a coisa (Larman) 7/18
Análise e Projeto OO A Análise OO tem o objetivo de encontrar e descrever os objetos (ou conceitos) do domínio do problema Em um sistema de informação de voo, por exemplo, alguns conceitos (objetos), incluem Avião, Voo e Piloto. O Projeto OO enfatiza na definição dos objetos de software e como eles colaboram entre si para satisfação dos requisitos. No sistema de informação de voo, o objeto avião pode ter um atributo numerodacauda e um método obterhistoricodovoo. 8/18
Análise e Projeto OO A orientação a objetos enfatiza a representação dos objetos. 9/18
Análise OO A análise de requisitos pode incluir narrativas ou cenários sobre como as pessoas irão utilizar a aplicação Na Análise OO, esse processo é comumente escrito no formato de casos de uso No exemplo a seguir, pode-se ver um caso de uso de um jogo simples de dados: Jogar um Jogo de Dados Um jogador pede que os dados sejam lançados. O sistema apresenta o resultado: se a soma do valor das faces totalizar sete, ele vence; caso contrário, ele perde. 10/18
Análise OO Os Casos de Uso podem ser representado por meio de diagramas: 11/18
Análise OO A Análise OO se preocupa com a criação de uma descrição do domínio, a partir da perspectiva de objetos. Durante a Análise OO tenta-se identificar os conceitos, atributos e associações considerados importantes. O resultado disso pode ser expresso em um modelo de domínio 12/18
Análise OO O modelo de domínio não é uma descrição dos objetos de SW, mas sim uma representação dos conceitos do mundo real. É chamado, também, de modelo conceitual de objetos O modelo de domínio pode ser projetado por meio do diagrama de classes da notação UML 13/18
Projeto OO O Projeto OO se preocupa com a definição de objetos de software e suas responsabilidades e colaborações. Uma notação comum para se representar essas colaborações é o diagrama de sequência 14/18
Projeto OO O diagrama de sequência é representado por meio de um diagrama de interação de UML O diagrama de sequência ilustra o fluxo de mensagens entre objetos de software O diagrama de sequência representa uma visão dinâmica de objetos colaborativos 15/18
Projeto OO Além da visão dinâmica, é útil criar uma representação estática das classes dos objetos Essa representação é feita por meio do diagrama de classes de projeto O diagrama de classes de projeto representa os atributos e métodos das classes 16/18
Projeto OO 17/18
Leitura Sugerida Estude o Capítulo 1 do livro de Craig Larman 18/18