Aula 1.7 Introdução a APOO e UML

APOO Aula 1.7 Introdução a APOO e UML Prof. Bruno Moreno bruno.moreno@ifrn.edu.br

Possuir um lápis e uma régua não te tornam um arquiteto 2

Você pode conhecer toda a API Java, C++ ou qualquer LPOO. 3

Mas para criar sistemas OO de alto nível, você precisa PENSAR EM OBJETOS! 4

A/POO: Motivações Como as responsabilidades devem ser atribuídas à classes de objetos? Como os objetos devem interagir? Quais classes devem fazer o que? Essas questões são importantes no projeto OO. 5

A/POO: Princípios O Projeto OO (e todo projeto de SW) está fortemente relacionado à atividade de prérequisitos: Análise de requisitos. Esta atividade inclui escrever casos de uso Casos de uso descrevem situações em que o sistema será utilizado. 6

A/POO: Princípios A atividade de análise de requisitos está presente na maioria dos processos de desenvolvimento; No contexto dessa disciplina, utilizaremos o Processo Unificado (PU) Entretanto, os conceitos trabalhados aqui poderão ser utilizados no contexto de qualquer processo de desenvolvimento Scrum, Feature-Driven Development, Lean Development, dentre outros. 7

Análise OO A análise pode ser vista como uma investigação dos problemas e dos requisitos; Análise não é uma solução, mas sim uma tentativa de se chegar a ela. Exemplo (sistema de vendas online): Como o sistema será utilizado? Quais são as funções do sistema? 8

Análise OO Durante a análise, tenta-se encontrar e descrever os objetos, ou conceitos, do domínio do problema; Exemplo de conceitos para um sistema de vendas online: Venda, Produto, cliente, etc.; 9

Projeto OO O projeto diz respeito a uma solução conceitual (que pode ser em software ou em hardware); Essa solução deve satisfazer os requisitos investigados na análise; Exemplo: Descrição de um esquema de banco de dados; 10

Projeto OO Durante o projeto OO, a ênfase está na definição dos objetos de software e como eles colaboram para satisfazer os requisitos; Exemplo de conceitos para um sistema de vendas online: O objeto de software produto pode ter um atributo tipo de produto e um método adiciona no carrinho; 11

Faça a coisa certa e faça certo a coisa 12

ANÁLISE Faça a coisa certa e faça certo a coisa PROJETO 13

Exemplo Desenvolver um jogo de dados no qual um jogador lançá dois dados. Se o total for sete, ele vence, caso contrário, perde. 14

Exemplo - Análise OO Roteiro: Definir casos de uso A análise de requisitos pode incluir diversos mecanismos para se investigar os requisitos: Narrativas ou cenários como as pessoas usarão o sistema, por exemplo; Narrativas e cenários podem ser escritos como casos de uso. 15

Exemplo - Análise OO Roteiro: Definir casos de uso Exemplo: 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 dos dados totalizar sete, ele vence; caso contrário, perde. 16

Exemplo - Análise OO Roteiro: Definir casos de uso Definir modelo de domínio A análise OO se preocupa com a criação de uma descrição do domínio, a partir da perspectiva de objetos; Aqui, identifica-se os principais conceitos, atributos e associações. 17

Exemplo - Análise OO Roteiro: Definir casos de uso Definir modelo de domínio O resultado dessa análise é descrito em um modelo de domínio O modelo de domínio descreve os conceitos (ou objetos) do domínio para auxiliar na compreensão do sistema em desenvolvimento; 18

Exemplo - Análise OO Roteiro: Definir casos de uso Definir modelo de domínio Exemplo: O modelo ilustra os conceitos de interesse, suas associações e atributos; O modelo de domínio não é uma descrição dos objetos de software, mas sim um modelo conceitual de objetos; 19

Exemplo - Análise OO Roteiro: Definir casos de uso Definir modelo de domínio Definir diagramas de interação O projeto OO se preocupa com a definição de objetos e suas responsabilidades e colaborações; Comumente se utiliza o diagrama de sequência em UML Mostra o fluxo das mensagens entre objetos. 20

Exemplo - Análise OO Roteiro: Definir casos de uso Definir modelo de domínio Definir diagramas de interação Exemplo: 21

Exemplo - Análise OO Roteiro: Definir casos de uso Definir modelo de domínio Definir diagramas de interação Definir diagramas de classes de projeto Os diagramas de interação criados na fase anterior são diagramas que demonstram a dinâmica do sistema; É útil, portanto, descrever uma visão estática do sistema: Diagrama de classes de projeto (UML). 22

Exemplo - Análise OO Roteiro: Definir casos de uso Definir modelo de domínio Definir diagramas de interação Definir diagramas de classes de projeto Exemplo: no jogo de dados, uma inspeção do diagrama de sequencia nos leva ao diagrama de classes a seguir: 23

Exemplo - Análise OO Exemplo 24

UML 25

Definição UML: Unified Markup Language (Linguagem de Modelagem Unificada); É uma linguagem visual utilizada para especificar, construir e documentar artefatos dos sistemas; 26

Introdução UML é uma linguagem VISUAL! É uma notação diagramática padrão utilizada para apresentar figuras relacionadas a um software OO; A UML é uma linguagem volumosa! Não trabalharemos com todos os conceitos da linguagem; 27

Aplicação de UML UML pode ser utilizada de, pelo menos, três modos: UML como rascunho; UML como planta de software; UML como linguagem de programação. 28

Aplicação de UML UML podem ser utilizadas de, pelo menos, três modos: UML como rascunho; UML como planta de software; UML como linguagem de programação. 29

UML como rasunho UML é bastante utilizado informalmente; Para tentar-se compreender partes complexas do sistema, por exemplo; 30

UML como planta de SW UMA planta detalhada de SW em UML pode ser utilizada tanto para (1) engenharia reversa como para (2) engenharia avante 32

UML como LP Atualmente, ferramentas CASE permitem a geração de código (Java, por exemplo) a partir de diagramas UML; Existem teorias sendo desenvolvidas para que UML seja utilizada, de fato, como linguagem de programação. 34

Como fazer o melhor uso de UML? 35

Melhor uso de UML É subjetivo; Para o desenvolvimento ágil de softwares, sugere-se que UML seja utilizado em forma de rascunho Veremos que uma vasta documentação não é o forte de metodologias ágeis. Não é saudável para o desenvolvimento fazer uso de diagramas complexos UML. 36

UML é a solução ideal para o desenvolvimento de software? 37

Para ajudar a responder essa pergunta, sugiro a leitura do artigo No Silver Bullet de Frederick Brooks. A entrega de um resumo do artigo até o dia 28/04 as 23:59. 38

Perspectivas de aplicação UML pode ser aplicado de acordo com três perspectivas: Perspectiva conceitual; Perspectiva de Especificação; Perspectiva de Implementação; Ou seja, uma mesma notação em UML pode ser utilizada para três perspectivas diferentes 39

Perspectivas de aplicação UML pode ser aplicado de acordo com três perspectivas: Perspectiva conceitual; Perspectiva de Especificação; Perspectiva de Implementação; 40

Perspectiva Conceitual Um notação do tipo Diagrama de Classes pode ser utilizada para representar um modelo de domínio, por exemplo: JogoDeDados Dado valordaface A perspectiva conceitual é utilizada para descrever coisas em uma situação do mundo real ou do domínio de interesse. 41

Perspectiva de Especificação A mesma notação de Diagrama de Classes pode ser utilizada para descrever elementos do software: JogoDeDados dado1: Dado dado2: Dado jogar() Dado valordaface: int obtervalordaface(): int lancar() Essa perspectiva não se compromete com uma linguagem em específico. 43

Perspectiva de Implementação Neste caso, os diagramas representam implementações de software em uma tecnologia particular Java, por exemplo. 45