Análise Orientada a Objetos

Prof. Eliseu Castelo Branco Jr.,PMP,MSc.ecastelob@gmail.com

Conceitos de Orientação a Objetos Visão Geral da UML Diagrama de Caso de Uso Diagrama de Classes Diagrama de Objetos Diagramas de Interação Diagrama de Estado Diagrama de Atividades Diagramas de Implementação

Ementa da Disciplina

Cronograma de Aulas

FEVEREIRO MARÇO ABRIL MAIO JUNHO2 2 6 4 19 9 AV1 - 13 11 8

23 16 20 18 AV2-15 23 27 25 22 30 AV3 - 29

3 5 4 4 5

TOTAL 21FREQ MIN 17

Provas sobre conteúdo teórico da disciplina (Av1, Av2, Av3)

Trabalhos de pesquisa publicados na Internet

Documentos de Análise e Projeto de software entregues

Exercícios realizados em sala de aula OBS: mínimo de 75% de presença em sala

de aula necessário para aprovação na disciplina.

Avaliações

Sistemas de software são complexos. O uso de modelos auxilia na compreensão

de conceitos complexos.

Introdução

O desenvolvimento de um sistema envolve grande quantidade de atividades e pessoas

Erros são inevitáveis e se identificados nos modelos sua correção é mais fácil e barata.

Introdução

O uso de modelos reduz o custo do desenvolvimento de sistemas.

O modelo permite prever o comportamento do sistema no futuro.

Introdução

A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares.

O que é modelagem de software?

“Paradigma é a forma de abordar um problema”

Princípios:1. Qualquer coisa é um objeto2. Objetos realizam tarefas através da requisição

de serviços a outros objetos3. Cada objeto pertence a uma classe4. A classe é um repositório para comportamento

associado ao objeto5. Classes são organizadas em hierarquias

Paradigma da Orientação a Objetos

O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados OBJETOS. Cada objeto realiza tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada.

Paradigma da Orientação a Objetos

Tipos de Sistemas

O Sistema contem subsistemas

Subsistemas de um Sistema de Informação

Módulos do Sistema (subsistemas)

Classe Movimentação Financeira Classe Bancos Classe Rendas Diversas Classe Contas a Pagar Classe Receitas Diversas

Subsistema Contas a Pagar

Classe Banco

Atributos

Métodos

O que é Análise e Projeto?

Análise — “o quê”

Investigação do problema e dos requisitos

Requisitos

Casos de uso

Restrições

Vocabulário

Projeto — “como”

Descrição de uma solução lógica

Objetos

Arquitetura

Instalação & Operação

Interface do usuário

Representação de um Conceito na APOO

Ex.: O conceito “Livro” em um sistema de biblioteca

Conceitode domínio

public class Livro{public void imprimir();

private String titulo;}

Representaçãono código

Livro

título

Representaçãona análise

Livro

título

Representaçãono projeto

imprimir()

Uma Analogia — Organizando os Negócios de uma Empresa

DocumentosAssociados

APOOAnalogia

Casos de usoAnálise de requisitosQuais são os processos de negócio?

Modelo conceitualAnálise do domínioQuais são os papeis dos empregados?

Diagramas de classes de projeto, diagramas de colaboração

Atribuição de responsabilidades, projeto das interações

Quem é responsável por o quê? Como eles interagem?

Um Exemplo — Jogo de Dados

Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete

Modelagem na APOO◦ Casos de uso

Descrições narrativas de processos do domínio no formato de prosa estruturada

Ex.:

Caso de uso:Atores:Descrição:

JogarJogadorEste caso de uso começa quandoo jogador rola os dados. Se o totaldos dados for sete, o jogador ganha;do contrário, ele perde.

Um Exemplo — Jogo de Dados

Modelagem na APOO (cont.)◦ Modelo conceitual Conceitos, atributos, e associações

que são considerados importantes no domínio da aplicação

Ex.:

◦ Um modelo conceitual descreve conceitos do mundo real, não componentes de software!

Jogador

nome

JogoDeDados

Dado

valor

Rola

Joga

Inclui

2

2

1

1

1

1

Um Exemplo — Jogo de Dados Modelagem na APOO (cont.)

◦ Diagramas de colaboração Alocação de responsabilidades para objetos

ilustrando como eles interagem via mensagens Mostram o fluxo de mensagens entre instâncias

e a invocação de métodos Ex.:

:Jogador d1 : Dado

d2 : Dado

joga() 1: r1 := rola()

2: r2 := rola()

Um Exemplo — Jogo de Dados

Modelagem na APOO (cont.) ◦ Diagramas de classes de projeto

Como os objetos (de software) se conectam? Quais são os métodos de uma classe? Ex.:

Rola

Joga

Inclui

2

2

Jogador

nome

joga()

Dado

valor

rola()

JogoDeDados

inicializa()

1

1

1

1

APOO X APE Metodologias mais antigas, como

Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição

Sistema deBiblioteca

Sistema

A&P Orientados a Objeto

Decomposição por objetos ou conceitos

A&P Estruturados

Decomposição por funções ou processos

RegistraEmpréstimos

AdicionaRecursos

ReportaMultas

Catálogo

Livro

Bibliotecário

Biblioteca

A Linguagem de Modelagem Unificada — UML

A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto

A notação (a própria UML) é relativamente trivial

Muito mais importante: habilidade para modelar com objetos◦ Só aprender a notação UML não ajuda

A UML não é◦ um processo ou metodologia◦ APOO◦ regras de projeto

Origem e Evolução da UML

Unified Method 0.8 Unificação I(Out’95)

Booch’93 OMT-2

Outros métodos Booch’91 OMT-1 OOSE Fragmentação

UML 1.0

Parceirosda UML

Padronização(Jan’97)

UML 1.1 Industrialização(Set’97)

UML 0.9 & 0.91 Unificação II(Out’96)

Processo de Desenvolvimento Organização das atividades relacionadas à

produção e manutenção de sistemas de software

Útil, mas um fator de segunda ordem◦ O principal: equipe qualificada

Boa equipe + bom processo = menor risco

O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria

Sol, Mar e UML

Visões da UML

Uma série de pesquisas (www.embeddded-forecast.com) tem mostrado que muitos projetos de software embarcados são entregues com atraso ou cancelados.

Em média, observou-se que mais de 50% dos projetos têm seus cronogramas atrasados em pelo menos quatro meses e cerca de 11% são cancelados.

O custo dos atrasos pode ser significativo. Por exemplo, no setor de aviônicos o custo dos atrasos é estimado de 50.000 a 300.000 dólares por mês.

Outro problema apontado é o nível de conformidade do produto final com as especificações.

Identificou-se que pelo menos 30% dos projetos não alcançavam 50% das especificações propostas de performance ou funcionalidade.

À medida que os sistemas embarcados aumentam em complexidade, esta situação tende a piorar.

A pesquisa mostrou também que adoção de UML (Unified Modeling Language) ainda não é uma prática comum.

Ações (*) : unidade básica de especificação de comportamento. Ações estão contidas em atividades

Artefatos (*) : Pedaço físico da informação usado ou produzido durante o desenvolvimento do sistema

Atividades Casos de Uso Classes Classes ativas Colaboração Componente Estado Interação Interface

Elementos básicos do modelo UML

No Nota Pacote Partes (*) Portas (*) Estereótipos (*) Valores de etiqueta (*) Restrições (*)

Elementos básicos do modelo UML