Análise Orientada a Objetos com UML
-
Upload
eliseu-castelo -
Category
Education
-
view
17.466 -
download
3
description
Transcript of Análise Orientada a Objetos com UML
Análise Orientada a Objetos
Prof. Eliseu Castelo Branco Jr.,PMP,[email protected]
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