análise e projeto de sistemas orientados a objetos · 2 prof. marco antônio pereira araújo,...
TRANSCRIPT
1
Análise e Projeto de Sistemas Orientados a
Objetos
Marco Antônio Pereira Araújo, [email protected]
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Organização� Introdução� Conceituação� Desenvolvimento Orientado a Objetos� UML (Unified Modeling Language)� RUP (Rational Unified Process)� Teste em Software Orientado a Objetos� Estratégias de Persistência de Objetos� Refatoração� Padrões de Projeto (Design Patterns)� Considerações Finais
2
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Bibliografia� BEZERRA, Eduardo. Princípios de Análise e Projeto de
Sistemas com UML. Campus, 2002.� BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar.
UML – Guia do Usuário. 2ª. ed. Campus, 2006. � FOWLER, Martin. UML Essencial. 3ª. ed. Bookman,
2005.� COCKBURN, Alistair. Escrevendo Casos de Uso
Eficazes. Bookman, 2005.� LARMAN, Craig. Utilizando UML e Padrões. 2ª. ed.
Bookman, 2004.� SCOTT, Kendal. O Processo Unificado Explicado.
Bookman, 2003.
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Bibliografia� GAMMA, Erich, et al. Padrões de Projeto – Soluções
Reutilizáveis de Software Orientado a Objetos. Bookman, 2000.
� FOWLER, Martin. Refatoração – Aperfeiçoando o Projeto de Código Existente. Bookman, 2004.
� SINTES, Anthony. Aprenda Programação Orientada a Objetos em 21 Dias. Makron Books, 2002.
� BINDER, Robert. Testing Object-Oriented Systems. Addison-Wesley, 1999.
� http://www.rational.com/uml� http://www.cetus-links.org� http://www.mundooo.com.br
3
Introdução
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Histórico
� Origens:�Linguagem SIMULA67: conceito de classe�Linguagem SMALLTALK
� Os conceitos básicos da OO já tiveram algumas décadas para amadurecimento
4
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Motivação� Noção intuitiva: o mundo é povoado por
objetos que interagem entre si� Melhor mapeamento: Mundo Real x
Mundo Computacional� Melhoria da qualidade e produtividade� Aumenta o grau de reutilização� Melhoria da manutenção� Melhor gerenciamento da complexidade
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Complexidade
5
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Métodos Estruturados x Orientados a Objetos
ESTRUTURADOS ORIENTADOS A OBJETOS
DECOMPOSIÇÃO
ENFOQUE
DADOS E PROCEDIMENTOS
TRANSIÇÃO DA ANÁLISE PARA PROJETO
ESTRUTURA DO SISTEMA
CICLO DE VIDA
FUNCIONAL
TOP-DOWN
EXECUÇÃO DO SISTEMA
NÃO BEM RESOLVIDO
HIERARQUIA DE FUNÇÕES
SEQUENCIAL
CHAMADA DE FUNÇÕES
OBJETO
TOP-DOWN E BOTTOM-UP
PROCEDIMENTOS ASSOCIADOS A DADOS
NATURAL OBJETO / CLASSE
HIERARQUIA DE CLASSES
ITERATIVO
PASSAGEM DE MENSAGENS
PROCEDIMENTOS NÃO ASSOCIADOS A DADOS
Conceituação
6
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Paradigma Orientado à Objetos
� Conjunto de conceitos e regras que determinam como desenvolver software utilizando a tecnologia de orientação àobjetos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Objetos� Representam elementos do mundo real� Possuem
�Atributos (estado)�Serviços (comportamento)� Identidade
7
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Atributos e Serviços� Atributo
� É um dado (informação de estado) para o qual cada objeto em uma classe tem seu próprio valor
� Serviço� É um comportamento específico que um objeto
deve exibir� Identidade
� Identifica de forma única um objeto, independente dos valores de seus atributos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Objetos
8
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Classe
� Uma descrição de um ou mais objetos com os mesmos atributos e serviços
� Uma classe pode ser vista como uma “fábrica de objetos”
� Objetos pertencentes à classe são ditos INSTÂNCIAS da classe
� Instanciação: ato de criar (instanciar) objetos de uma classe
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Classe
9
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Tipos de Classes
� Classe Concreta�Pode instanciar objetos
� Classe Abstrata�Não pode instanciar objetos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
CorProprietário
Ano
VerdeMaria1995
AzulJoão1992
Classe e ObjetosClasse Automóvel
Atributos: cor, proprietário, ano,
etc.
Classe Automóvel
Serviços: acelerar, frear, abastecer,
etc.
10
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Classificação
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Dificuldade da Classificação
11
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Abstração
� Princípio de ignorar os aspectos de um assunto não relevantes para o propósito em questão, tornando possível uma concentração maior nos assuntos principais
� A abstração consiste então na seleção de alguns aspectos, ignorando outros
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Abstração
12
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Encapsulamento (Ocultamento de Informações)
� O encapsulamento proíbe a visualização interna de um objeto
� Atributos são associados à serviços e sópodem ser acessados por estes
� A interface para cada módulo é definida de forma a revelar o menos possível sobre seu funcionamento interno
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Encapsulamento
� Serviços só têm acesso aos atributos da classe para a qual foram definidos
� Atributos de uma classe só podem ser manipulados por serviços desta classe
Atributos
Serviços (ou Métodos)
13
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Encapsulamento
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Herança� Mecanismo para expressar a
similaridade entre classes, simplificando a definição de classes iguais a outras que já foram definidas
� Representa a estrutura Generalização e Especialização, tornando explícitos os atributos e serviços comuns em uma hierarquia de classes
14
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Herança
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Herança� Superclasses representam abstrações
generalizadas� Subclasses representam abstrações onde
variáveis de instância e métodos são adicionados, modificados ou removidos
� Relacionamento do tipo “é-um”� Superclasses podem possuir serviços virtuais,
que podem ser redefinidos nas subclasses� Superclasses podem possuir serviços abstratos,
que devem ser implementados nas subclasses, não possuindo implementação na superclasse
15
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Herança
� Com o mecanismo de herança, ao se criar uma classe a partir de outra classe, a nova classe (subclasse da classe original) herda todas as suas características (atributos e serviços)
� Dois tipos�Simples�Múltipla
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Herança Simples
� Subclasse herda de apenas uma superclasse
Generalização Superclasse
Especialização Subclasse
Veículo Terrestre
Automóvel
16
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Herança Múltipla� Subclasse herda de mais de uma
superclasse�Principal problema: conflito de nomes
Veículo Terrestre
Anfíbio
Generalização Superclasse
Especialização Subclasse
Veículo Aquático
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Polimorfismo
� Possibilidade de enviar um mesmo seletor de mensagem para diferentes objetos, mesmo que estes sejam instâncias de classes diferentes
� Significa que a mesma operação pode atuar de modos diferentes em classes diferentes
17
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Associação� Um modelo de mapeamento de domínio que
um objeto precisa ter com outros, para cumprir suas responsabilidades
� Tipos:� 1:1 - atributo simples (objeto) em ambas as
classes da associação� 1:N - atributo simples (objeto) em uma das
classes da associação e atributo coleção (lista) na outra classe
� N:N - atributo coleção (lista) em ambas as classes da associação
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Composição / Agregação� Utilizado quando objetos de
determinadas classes são utilizados em conjunto e um faz parte do outro
� Representa a estrutura Todo-Parte� Relacionamento do tipo “tem-um”� Composição: relacionamento mais forte
�Ex. Carro e Motor em Locação de Veículos� Agregação: relacionamento mais fraco
�Ex. Carro e Motor em Ferro-Velho
18
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Composição / Agregação
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Mensagens� Paradigma utilizado para comunicação
entre objetos� A independência de objetos é
enfatizada através da troca de mensagens
� Os dados de um objeto não podem ser manipulados ou vistos por outro objeto, ao invés disso, uma mensagem éenviada ao objeto
19
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Mensagens
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Persistência
� Relaciona-se com a sobrevivência (armazenamento) do objeto
� O objeto é livre para sobreviver à morte de seu criador
� Objetos podem ser persistentes ou não
20
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Persistência
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Construção da Aplicação
21
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Tipificação Forte
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Ligação Dinâmica� Objetos só existem em tempo de
execução� Habilidade de uma operação ser
executada diferentemente de acordo com o tipo (classe) a que um objeto estáassociado
� Significa que a ligação (acoplamento) de uma mensagem com seu método correspondente é feito em tempo de execução
22
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização� O reuso é inerente ao processo de
solução de problemas utilizado pelos seres humanos
� Na medida em que soluções são encontradas, estas são utilizadas em problemas similares
� A capacidade de abstração é o que garante a adaptação necessária ao novo contexto
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização� Definições
�É a utilização de produtos de software desenvolvidos ao longo do ciclo de vida em uma situação diferente daquela para a qual foram originalmente produzidos
�É o processo de utilização de software pré-existente (programas, procedimentos, documentação e dados associados) durante o desenvolvimento de um novo sistema ou componente
23
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização
� Motivação�Melhores índices de produtividade�Produtos de melhor qualidade, mais
confiáveis, consistentes e padronizados�Redução dos custos e tempo envolvidos
no desenvolvimento de software�Maior flexibilidade na estrutura do software
produzido, facilitando sua manutenção e evolução
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização� Objetos de reutilização
� Código (rotinas, programas, componentes)� Projeto (informações sobre o projeto, decisões de
projeto, arquiteturas)� Análise (requisitos, especificações, aspectos sobre o
domínio da aplicação)� Conhecimento (formal e informal, sobre o domínio de
aplicação, sobre computação, experiência passada)� Processos de desenvolvimento de software
24
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização
� Objetos existentes são novamente aproveitados, com pouca ou nenhuma alteração
� É um benefício somente alcançado a longo prazo
� Somente é alcançada nos sistemas OO bem-construídos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização
� Deve ser criada uma biblioteca de classes reutilizáveis
� Para que possa ser efetiva, sistemas devem ser desenvolvidos para serem reutilizados, e não apenas reutilizando objetos existentes
� A OO não garante a reutilização, apenas a possibilita
25
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização� Atividades do processo de reutilização
�Compreensão do alvo de reutilização� Identificação de candidatos à reutilização�Avaliação do potencial de reutilização de
cada candidato e seleção do mais adequado�Modificação do objeto selecionado (se
necessário)� Integração do objeto modificado ao
processo de desenvolvimento
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização� Construtores de Classes
(Desenvolvimento para o Reuso)� Utilizadores de Classes
(Desenvolvimento com Reuso)
26
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Frameworks� Conjunto de classes que incorpora um
projeto abstrato para uma família de problemas que se relacionam, e suporta a reutilização em uma granularidade maior que a de classes
� Podem ser considerados como projetos ou arquiteturas de alto nível, consistindo de classes que são especialmente projetadas para serem refinadas e usadas em grupo
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Framework “Caixa-Branca”�O comportamento específico da aplicação é
inserido na arquitetura genérica, somando-se métodos às subclasses de uma ou mais classes do framework.
�Os frameworks que fazem uso deste processo de especialização obrigam quem os utiliza a conhecer os seus dispositivos internos
�São mais flexíveis e permitem a sua utilização na especificação de aplicações até então desconhecidas dentro do domínio
27
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Framework “Caixa-Preta”�O framework recebe um conjunto de
parâmetros que representa o comportamento específico da aplicação. Este fornecimento de parâmetros é feito por protocolo, através da interface de cada classe do framework e, por isso, esta forma de especialização requer que seja conhecida apenas esta interface
�Facilita a reutilização, pois exige que apenas a sua interface seja compreendida, podendo ser, portanto, encarado como um grande componente que encapsula o comportamento genérico de um domínio
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização� Fatores de influência
�Tamanho do programa: quanto maior é o programa, maior é a chance de se tornar complexo, dificultando sua compreensão e/ou modificação, reduzindo suas possibilidades de reutilização
�Estrutura do programa: influi diretamente na compreensão e/ou modificação do programa. Estruturas complexas reduzem a chance de reutilização
28
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização
�Linguagem de programação: bibliotecas formadas por componentes escritos em diferentes linguagens de programação. A reutilização pode implicar na conversão entre linguagens
�Documentação: a insuficiência de documentação interna (comentários) e externa (especificação, projeto, etc.) pode impossibilitar a reutilização
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização�Agente da reutilização: quanto mais
experiente for o agente da reutilização (na área de aplicação e em aspectos computacionais), mais facilmente ele serácapaz de compreender e/ou modificar componentes, portanto, reutilizá-los
�Grau de generalidade: quanto mais genérico for o objeto de reutilização, maiores serão as chances de ser reutilizado
29
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Reutilização� Independência: quanto mais independente
(de hardware e de software), maiores as chances de reutilização
�Coesão: força que mantém unidos os elementos de um objeto de reutilização. Quanto maior for a coesão, mais reutilizável será o objeto
�Acoplamento: grau de interdependência entre objetos. Quanto menor for o acoplamento, mais reutilizável será o objeto
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Tecnologias Orientadas àObjetos x Baseadas em Objetos� As orientadas à objetos suportam todos os
conceitos como encapsulamento, heranças nas classes e polimorfismo nas operações
� As baseadas em objetos apenas aderem parcialmente a estes conceitos
� Nem todas as ferramentas visuais são orientadas à objetos
30
Desenvolvimento Orientado a Objetos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Processo de Desenvolvimento
� Define o modelo que será utilizado para o desenvolvimento do produto
� Normalmente, engloba�Ciclo de Vida�Métodos�Ferramentas
31
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Desenvolvimento OO
� Em geral, envolve as seguintes atividades�Levantamento dos requisitos� Identificação de candidatos a classes/objetos� Identificação das interações entre objetos e
classes�Projeto�Codificação�Testes
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Ciclo de Vida
� A OO incentiva o desenvolvimento através de um processo incremental e interativo, com refinamento crescente do software
� Essa abordagem é facilitada pela utilização de um modelo homogêneo para a representação das etapas de desenvolvimento do software
32
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Ciclo de Vida em Espiral
� Meta-Modelo: qualquer ciclo de vida pode ser utilizado na fase de desenvolvimento
� A medida que componentes são desenvolvidos�Os componentes são avaliados�O desenvolvimento futuro é replanejado�Riscos são avaliados�O ciclo termina com o produto pronto
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Ciclo de Vida em Espiral
PlanejamentoAnálise
de Riscos
DesenvolvimentoValidação
33
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Análise Orientada à Objetos� OOA = Object Oriented Analysis
(Análise Orientada à Objetos)� Em OO, um modelo é construído
utilizando classes, e não objetos do mundo real (as instâncias)
� Etapas�Encontre as classes� Identifique os relacionamentos�Defina atributos�Defina serviços
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Projeto Orientado à Objetos
� OOD = Object Oriented Design (Projeto Orientado à Objetos)
� O projeto OO utiliza as mesmas ferramentas da análise, resultando num gap semântico muito menor entre as fases de desenvolvimento de sistemas, possibilitando uma transição da análise para o projeto mais eficiente
34
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Projeto Orientado à Objetos
� O projeto OO transforma as abstrações do domínio em classes implementáveis, embora nem todas as classes venham do domínio
� No projeto OO, basta acrescentar ao modelo de análise as classes que irão tratar da interação humana e de aspectos computacionais
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Projeto Orientado à Objetos� Os sistemas devem ser construídos em 3
camadas, isolando os objetos de interface dos objetos de domínio, e estes da camada de acesso ao banco de dados
� Etapas� Refine o modelo (verificar herança simples e
múltipla, incluir classes para o sistema e para conjuntos de objetos, caso necessário)
� Projete o gerente de dados (persistência)� Projete o gerente de interface� Projete o(s) gerente(s) de tarefas (relatórios,
consultas, estatísticas, etc.)
35
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Programação Orientada àObjetos� OOP = Object Oriented Programming
(Programação Orientada à Objetos)� Deixar a OO limitada à programação será
extremamente limitante e de poucos ganhos quanto à produtividade
� É importante “pensar” em objetos desde a análise
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Principais Linguagens� Puras: forçam o uso do paradigma OO
�Smalltalk�Java�Eiffel
� Híbridas: permitem a utilização de diferentes paradigmas�C++�Object Pascal�OOCobol
36
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Métodos Orientados a Objetos
� Um Método de Desenvolvimento de Software é um conjunto de procedimentos técnicos e convenções notacionais para a construção organizada de produtos de software
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Principais Métodos
� Coad & Yourdon� Booch� Rumbaugh (OMT)� Jacobson (Use case)� Unified Method / UML� Fusion� Shlaer-Mellor
37
UMLUnified Modeling Language
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Definição� Uma evolução das representações tradicionais
para análise e projeto� Unifica as formas de representação de Booch,
Rumbaugh e Jacobson� Adotado como padrão pela OMG (Object
Management Group)
38
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Definição� Normalmente é definido como uma linguagem
de modelagem e não um método propriamente dito
� Uma proposta de processo de desenvolvimento que pode ser utilizada em conjunto é o RUP (Rational Unified Process), definido por Booch, Jacobson e Rumbaugh
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - HistóricoNov ‘97 UML é aprovada pelo OMG
39
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� A UML pode ser utilizada para� Mostrar a periferia de um sistema e suas maiores
funções usando Casos de Uso e Atores� Ilustrar realizações de Casos de Uso com
Diagramas de Interações� Representar a estrutura estática de um sistema
usando Diagramas de Classes� Modelar o comportamento de objetos com
Diagramas de Estado� Revelar a arquitetura de implementação física com
Diagramas de Componentes e Distribuição
UML - Utilização
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos� Uma condição ou capacidade necessária
para um usuário resolver um problema ou alcançar um objetivo
� Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema
� Requisitos Funcionais: descrevem uma interação entre o sistema e seu ambiente
� Requisitos Não Funcionais (ou Restrições): descrevem uma restrição para o sistema que limita as possíveis escolhas de solução para o problema
40
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos
� Uma especificação de requisitos é importante porque:� Estabelece uma base de concordância entre o cliente
e o fornecedor sobre o que o software fará� Fornece uma referência para a validação do produto
final� Uma especificação de requisitos de alta qualidade é
um pré-requisito para um software de alta qualidade� Reduz o custo do desenvolvimento
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos (Padrão IEEE 830)� Estrutura de um documento de requisitos
� Título� Índice� Introdução
� Propósito� Escopo � Definições
� Descrição Geral� Visão Geral� Perspectiva do Produto� Funções do Produto
� Requisitos� Requisitos Funcionais� Requisitos Não Funcionais
41
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos Funcionais - Exemplos� Requisito Funcional 1: O sistema deve permitir à secretaria
cadastrar cursos, contendo código, descrição, carga horária, professor coordenador, quantidade de períodos e tipo de curso (Graduação, Especialização, Mestrado e Doutorado).
� Requisito Funcional 2: O sistema deve permitir à secretaria cadastrar disciplinas, contendo curso, código da disciplina, descrição, período, número de aulas, ementa e bibliografia, bem como seus pré-requisitos.
� Requisito Funcional 3: O sistema deve permitir à secretaria cadastrar alunos contendo matrícula, nome, data de nascimento, curso, ano de início, semestre de início, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, endereço completo (logradouro, número, complemento, bairro, cidade, UF, CEP), CPF, documento de identidade (número, órgão expedidor, UF e data expedição).
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos Funcionais - Exemplos� Requisito Funcional 4: O sistema deve permitir à
secretaria cadastrar professores, contendo matrícula, nome, data de nascimento, data de admissão, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, endereço completo (logradouro, número, complemento, bairro, cidade, UF, CEP), CPF, documento de identidade (número, órgão expedidor, UF e data expedição), titulação máxima (graduação, especialização, mestrado e doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo professor.
� Requisito Funcional 5: O sistema deve permitir àsecretaria cadastrar turmas, contendo curso, disciplina, ano, semestre, descrição da turma, número máximo de alunos, horários e professor responsável.
42
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos Funcionais - Exemplos� Requisito Funcional 6: O sistema deve permitir à
secretaria matricular alunos em turmas específicas.� Requisito Funcional 7: O sistema deve permitir ao
professor cadastrar avaliações e freqüência de alunos de uma turma específica.
� Requisito Funcional 8: O sistema deve calcular a aprovação de alunos, considerando 75% de freqüência mínima. Além disso, média menor do que 3 (três), implica em reprovação, média maior ou igual a 3 (três) e menor que 7 (sete) implica em prova final e média igual ou superior à 7 (sete) implica em aprovação. Para a prova final, a média desta nota com a média anterior menor ou igual a 5 (cinco) implica em reprovação, caso contrário, em aprovação.
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos Funcionais - Exemplos� Requisito Funcional 9: O sistema deve permitir ao
professor a emissão da relação de alunos por turmas, contendo descrição do curso, nome da disciplina, ano, semestre, turma, nome do professor, matrícula do aluno e nome do aluno.
� Requisito Funcional 10: O sistema deve permitir àsecretaria a emissão da relação de disciplinas por curso, contendo nome do curso, nome das disciplinas, total de disciplinas por curso e total de todas as disciplinas.
� Requisito Funcional 11: O sistema deve permitir àsecretaria a emissão do histórico escolar, contendo matrícula do aluno, nome do aluno, ano, semestre, nome das disciplinas, número de aulas, número de faltas e avaliações.
43
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Requisitos Não Funcionais -Exemplos� Requisito não funcional 1: O sistema deve possibilitar
que todos os relatórios sejam pré-visualizados antes do envio para a impressora.
� Requisito não funcional 2: O sistema deve apresentar o recurso de ajuda on-line sensível ao contexto.
� Requisito não funcional 3: O sistema deve processar matrículas em, no máximo, 5 segundos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Use Cases�Tipicamente representa uma interação entre
um usuário e um sistema computacional�Pode ser utilizado para capturar os contextos
de utilização do sistema�Tem a capacidade de representar os
requisitos do sistema em alto nível de abstração
�É um padrão de comportamento que o sistema exibe
�Apresenta uma visão externa do sistema
44
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Use Cases�Elementos que compõem um diagrama de
use cases� Ator: representa um papel que um usuário
desempenha com respeito ao sistema� Situação (use case): representa as
funcionalidades externas do sistema� Extensões: representam extensões à situações
pré-definidas� Usos: demonstram a reutilização de situações
pré-definidas
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� Atores� Um Ator é alguém ou alguma coisa que deve
interagir com o sistema a ser desenvolvido� Cada caso de uso é uma seqüência de
transações relacionadas executadas por um ator e o sistema, em um diálogo
Aluno
Secretaria
Professor
Sistema Faturamento
UML - Use Cases
45
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� Atores são examinados para determinar suas necessidades� Coordenador: manter o currículo� Professor: solicitar lista de cursos� Aluno: efetuar matrícula� Sistema Cobrança: recebe informações sobre
cobranças
Efetuar MatrículaCadastrar Aluno Emitir Histórico Escolar
UML - Use Cases
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� Diagramas de use case são criados para se visualizar a relação entre atores e casos de uso
Secretaria
Secretaria
Secretaria
Emitir Histórico Escolar
Efetuar Matrícula
Cadastrar Aluno
Aluno
UML - Use Cases
46
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Use Cases� À medida em que casos de uso são
documentados, outras relações entre casos de uso poderão ser descobertas� Uma relação de uso (use) mostra comportamento
que é comum a a um ou mais casos de uso� Uma relação de extensão (extend) mostra
comportamento opcionalEfetuar Matrícula
<<use>>
Validar Senha<<use>>
Emitir Histórico Escolar
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Use Cases
Secretaria
Emitir Declaração Matrícula
Efetuar Matrícula
<<extend>>
47
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Diagrama de Casos de Uso
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML- Especificação de Casos de Uso� Caso de Uso� Super Caso de Uso� Sumário� Ator Principal� Atores Secundários� Pré-Condições� Curso Normal� Cursos Alternativos� Cursos de Exceção� Pós-Condições� Requisitos Não Funcionais� Requisitos de Interface com o Usuário� Regras do Negócio
48
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Caso de Uso: Matricular Aluno
Super Caso de Uso:Não de aplica
Sumário:Este caso de uso é iniciado pela secretaria quando da matrícula de um aluno em uma turma de uma determinada disciplina.
Ator Principal:Secretaria
Ator Secundário:Não se aplica
Pré-Condições:Usuário da secretaria logado no sistema
UML- Especificação de Casos de Uso
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Curso Normal:1. Secretaria solicita ao sistema a matrícula de alunos;2. Sistema exibe uma lista com as turmas cadastradas, contendo descrição do
curso, descrição da disciplina, ano, semestre e descrição da turma;3. Sistema solicita a opção de matricular alunos a partir da seleção de uma
turma na lista de turmas disponibilizada;4. Secretaria seleciona uma turma;5. Sistema exibe a lista de alunos matriculados na turma, professor
responsável, total de vagas e vagas restantes;6. Sistema solicita o número de matrícula do aluno;7. Secretaria informa o número de matrícula do aluno;8. Sistema solicita confirmação da matrícula;9. Secretaria confirma os dados;10. Sistema efetua validação da matrícula (RN1) (RN2) (RN3);11. Sistema armazena a matrícula;12. Sistema fecha a interface.
UML- Especificação de Casos de Uso
49
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Cursos Alternativos:a) Cancelamento da operação de matrícula
Entre os passos 1 e 8, a Secretaria pode cancelar a operação de matrícula, fechando a interface;
Cursos de Exceção:a) A turma está com o número total de vagas preenchidas
Sistema avisa que a matrícula não poderá ser efetuada e o caso de uso se encerra;
b) O aluno não é do curso da turma selecionadaSistema avisa que a matrícula não poderá ser efetuada e o caso de uso se encerra;
c) O aluno não está na situação de matriculadoSistema avisa que a matrícula não poderá ser efetuada e o caso de uso se encerra;
UML- Especificação de Casos de Uso
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Pós-Condições:Podem ser lançadas avaliações para este aluno nesta turma
Requisitos Não Funcionais:Não se aplica
Requisitos de Interface com o Usuário:O sistema deve fornecer uma interface gráfica com facilidades para pesquisa de turmas através de nomes de cursos e nomes de disciplinas.
Regras do Negócio:RN 1: Um aluno só pode se matricular em disciplinas que tenha obtido aprovação em seus pré-requisitosRN 2: Um aluno não pode matricular-se em turmas com coincidência de horáriosRN 3: Não podem ser matriculados alunos além do limite de vagas da turma
UML- Especificação de Casos de Uso
50
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes� Descreve os tipos dos objetos existentes no sistema e
as associações estáticas entre eles� As principais relações estáticas são
� Classes, suas estruturas internas e comportamento� Associações, composições, agregações, dependências, e
relações de herança� Multiplicidade e indicadores de navegação� Nomes de papéis (o que uma classe representa para outra)
� Mostram também os atributos, operações e restrições que se aplicam aos objetos de uma determinada classe
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes� Classes
� Representam os tipos de objetos existentes no modelo
� Descritas a partir de seus atributos, operações e restrições
� Podem ser organizadas segundo uma estrutura de generalização/especialização
� Admitem classificação simplesou múltipla (herança simples ou múltipla)
� Nome da classe em itálico representa classe abstrata
ClasseAtributos
Operações( )
51
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML- Herança� Herança é uma relação entre uma
super-classe e suas sub-classes� Atributos comuns, operações, relações
e/ou, são mostradas no nível aplicável mais alto da hierarquia
Generalização
Es pec ialização 1 Es pecialização 2
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes� Associações
� Representam relacionamentos entre instâncias de classes (um aluno se matricula em um curso, um curso possui várias disciplinas)
� Conceitualmente representam relacionamentos entre classes
� Possuem 2 papéis, um para cada sentido da associação, que pode ser explicitamente representado por um label Associação
Classe 2 Classe 1
min..max min..max
52
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes Associação� Multiplicidade define como muitos
objetos participam numa relação� Multiplicidade é o número de instâncias de uma
classe que se relacionam a UMA instância de uma outra classe
� Para cada associação e agregação, haverá duas decisões relativas a multiplicidade a se tomar: uma para cada lado da relação
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes� Associações
� A multiplicidade de um papel representa o número de objetos que pode participar da associação
� Do ponto de vista da especificação do sistema as associações representam responsabilidades
� Do ponto de vista de implementação associações indicam a existência de referências entre os objetos, e servem para indicar a navegabilidade do modelo
53
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes
� Multiplicidade de Associações
ClasseClasse* Muitos (0 ou mais)
ClasseClasseExatamente um 1..* 1 ou mais
1-3,5 Possibilidades específicas
Classe0..1 Opcional (0 ou 1)
Curso Disciplinacódigo código
Contêm
É-composto-de
1..**
Está-incluída
1
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes Associação
� Relações fornecem um caminho para a comunicação entre os objetos
� Diagramas de sequência e/ou comunicação podem identificar ligações entre objetos para se chegar ao comportamento desejado
� Tipos de relações� Associação� Agregação� Composição� Dependência
54
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� Uma associação é uma conexão bi-direcional entre classes�Uma associação é mostrada como uma linha
conectando as classes relacionadas� Uma agregação é um tipo mais forte de
conexão, onde a relação é entre o todo e suas partes�Uma agregação é mostrada como uma linha
conectando as classes relacionadas com um losango perto da classes que representa o todo
UML - Diagrama de Classes Associação
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes Associação� Uma relação de dependência é uma forma mais
fraca de relação, mostrando uma relação entre um cliente e um fornecedor, onde o cliente não tem conhecimento semântico do fornecedor�Uma dependência é mostrada como uma
linha pontilhada entre o cliente e o fornecedor
55
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes� Associações
Classe A Classe B
Classe Associativa
min..max min..max
Agregação
min..max min..max
ParteTodo
DependênciaClasse 1 Classe 2
ComposiçãoTodo Parte
min..max min..max
AssociaçãoClasse 2 Classe 1
min..max min..max
Anotação
Classe B
NavegabilidadeClasse 2 Classe 1
min..max min..max
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes
56
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes Associação
� Apesar de associações e agregações serem bi-direcionais por definição, frequentemente édesejável restringir a navegação em uma única direção� Caso a navegação seja restringida, uma seta é adicionada para se
indicar a direção da navegação
� Muitas vezes é conveniente definir a navegabilidade a partir dos diagramas de seqüência
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes� A estrutura de uma classe é representada
pelos seus atributos� O comportamento de uma classe
é representado pelas suas operações� Atributos podem ser encontrados pelo exame
das definições de classes, requisitos de problemas, e pela aplicação do conhecimento do domínio
Cada Disciplina oferecidapossui uma ementa e umabibliografia
DisciplinaEmentaBibliografia
57
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML - Diagrama de Classes
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML – Especificação de Classes
� Atributos� Nome� Descrição� Tipo (Integer, Real, Boolean, Character, Classe)� Tamanho� Visibilidade� Obrigatoriedade� Restrições
58
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UML – Especificação de Classes
� Serviços� Nome� Descrição� Tipo (Procedimento / Função)� Parâmetros (Opcional)
� Nome� Tipo� Tamanho� Obrigatoriedade
� Tipo de Saída (para Funções)
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� Diagramas de Interação descrevem como casos de uso são realizados como interações entre associações de objetos
UMLDiagramas de Interação
59
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagramas de Interação� Diagrama de Interação
� Modelos que descrevem como grupos de objetos colaboram para obter algum comportamento
� Tipicamente um diagrama de interação captura o comportamento de um único caso de uso
� Há dois tipos de Diagramas de Interação� Diagramas de Seqüência� Diagramas de Comunicação
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� Um Diagrama de Seqüência mostra interações de objetos ordenados numa seqüência de tempo
� Operações podem ser encontradas examinando-se os Diagramas de Interação
� Relacionamentos podem ser descobertos examinando-se os Diagramas de Interação
UML - Diagrama de Seqüência
60
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Diagrama de classes após a construção do diagrama de seqüência
61
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
� Um Diagrama de Comunicação mostra interações organizadas à volta de objetos e as ligações de um para o outro
UMLDiagrama de Comunicação
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
62
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Estados� Mostra os estados de uma determinada classe,
os eventos que causam a transição de um estado para outro e as ações resultantes da troca de estados
� Representa a visão do modelo dinâmico de uma simples classe ou do sistema como um todo
� Diagramas de Estados são criados para objetos que tenham um comportamento dinâmico significante
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Estados� Estados
�Representam os resultados acumulativos do comportamento de um objeto
� Transições (eventos)�Alguma ocorrência que pode causar a troca
do estado de um sistema
63
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Estados
Matriculado
Trancado
Formado
Abandono
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Estados� Notação Avançada
�Ações dos Estados� Ações podem ser associadas a estados
�Transição Condicional� Transições somente ocorrerão se satisfizerem a
determinadas condições�Estados aninhados
� Estados podem ser particionados
64
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Estados
Iniciar Ação Abrirentrar: Matricular Aluno
Sair: incrementa contador
Fechado
Cancelado
fazer: iniciar curso
fazer: Finalize curso
fazer: Notificar Aluno Matriculado
Incluir Aluno / Contador = 0
Inclui aluno[ contador < 10 ]
[ contador = 10 ]
Cancelar
Cancelar
Cancelar
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Atividades� Utilizados para modelar o fluxo de atividades em
um procedimento� Decisões podem ser representadas quando
mais de um evento pode ocorrer em uma atividade
� Atividades são equivalentes aos estados� Eventos são equivalentes às transições� Normalmente são associados a diagramas de
estados
65
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Atividades
� Um Diagrama de Atividades pode ser usado com diferentes propósitos, incluindo� Capturar o trabalho que será executado quando
uma operação é disparada (ações)� Capturar o trabalho interno em um objeto� Mostrar como um grupo de ações relacionadas
pode ser executadas, e como vão afetar outros objetos
� Mostrar como uma instância de caso de uso pode ser executada em termos de ações e objetos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Atividades
Atividade A Atividade B
Início Atividade inicial Atividade X Fim
Transição
Atividade B
Atividade C Atividade D
Decisão Saída A
Saída B A barra indica que uma atividade despacha para várias que ocorrem em paralelo ou em ordem não previsível
66
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Atividades
Matricular Aluno
Cancelar matrícula
Verificar Horários Verificar Pré-Requisitos
Aceitar matrícula
[Horários e Pré-Requistos OK]
[para cada pré requisito da disciplina]
negado [ok] [ok]
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Empacotamento� Representa as classes e seus relacionamentos� Mostra uma visão da estrutura de classes do
sistema� Indicam os papéis e responsabilidades das
entidades que provêem o comportamento do sistema
67
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Empacotamento
Interface doUsuário
Objetos doSistema
Banco de Dados
Utilidades
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Empacotamento
Academico Faturamento
Aluno(from Acadêmico)
Mensalidade
Aluno
68
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Componentes
� Diagramas de Componentes ilustram a organização e dependências entre componentes de software
� Um componente pode ser�Um componente de código fonte�Um componente de run-time, ou�Um componente executável
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Componentes
Curso Disciplina
Aluno Professor
curso.dll
pessoas.dll
curso
Usuário
Registro.exeCobrança.exe
SistemaCobrança
69
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Desenvolvimento
� Apresenta os relacionamentos físicos entre os componentes de software e hardware que compõem o sistema
� É bastante útil para apresentar a distribuição dos componentes no sistema
� Os nós do diagrama representam algum tipo de unidade computacional
� Conexões entre os nós mostram algum tipo de comunicação
� Componentes representam módulos físicos (código)� As dependências entre os componentes devem ser
as mesmas que as existentes entre os pacotes
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Desenvolvimento
<<TCP/IP>>
<<TCP/IP>>
SQL <<TCP/IP>>
ClienteA :Pentium 200
ClienteB :Pentium 200
Servidor deAplicação
Servidor deBanco deDados :
ORACLE 8
70
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Distribuição
� O Diagrama de Distribuição mostra a configuração dos elementos de processamento run-time e dos processos que rodam dentro deles
� O Diagrama de Distribuição visualiza a distribuição dos componentes através de toda a empresa
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
UMLDiagrama de Distribuição
Matrícula Database
Biblioteca
Salas
SedePrincipal
71
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
Ferramentas CASE
� Rational Rose� Visual Paradigm� Argo UML� Poseidon� Jude� System Architect
RUPRational Unified Process
72
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPDefinição� RUP é um framework genérico de um
processo de desenvolvimento� RUP é baseado em componentes� RUP utiliza toda a definição da UML� RUP é dirigido pelos use cases, centrado
na arquitetura, iterativo e incremental (conceitos-chave)
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPDefinição� Conjunto de atividades
� bem definidas � com responsáveis� com artefatos de entrada e saída� com dependências entre as mesmas e ordem de
execução� com modelo de ciclo de vida� descrição sistemática de como devem ser realizadas
73
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPCaracterísticas Principais� O desenvolvimento de sistemas seguindo
o RUP é� Iterativo e incremental�Guiado por casos de uso (use cases)�Baseado na arquitetura do sistema
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPFases
� O ciclo de vida de um sistema consiste de quatro fases, divididas em iterações
Concepção (define o escopo do projeto)Elaboração (define os requisitos e a arquitetura)Construção (desenvolve o sistema)Transição (implanta o sistema)
Tempo
Concepção Elaboração Construção Transição
Marco doObjetivo
(no Ciclo de Vida)
Marco daArquitetura
(no Ciclo de Vida)
Marco Capacidade Inicialde Operação
Marco daLiberaçãodo Produto
74
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPConcepção� Responder às seguintes perguntas
� Quais serão as principais funcionalidades do sistema?� Em linhas gerais, como será a arquitetura do sistema?� Qual é a estimativa inicial de tempo e custo para o projeto?� Quais são os principais riscos?
� Entendimento geral do problema e da tecnologia envolvida
� Estabelecer o escopo do projeto� Garantir o financiamento do projeto� Verificar a viabilidade do projeto
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPElaboração� Detalhamento dos requisitos do sistema� Protótipo Descartável – Interface com Usuário� Garantir uma arquitetura estável e testada para a
Construção (evitar surpresas técnicas durante a Construção)
� Minimizar os riscos relacionados à fase de construção� Plano de desenvolvimento para as próximas fases� Estimativa realista de custo e prazo para a Construção
75
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPConstrução� Construção do produto em uma sequência de iterações� Ênfase em Projeto Detalhado, Implementação e Testes� Construção em incrementos sucessivos� Gerar o software propriamente dito� Manuais / Documentação do usuário� Produto ao final da Construção ainda pode conter erros,
que serão descobertos e removidos na fase de Transição
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPTransição� Fazer a transição do produto para a comunidade de
usuários� Foco na correção de problemas e não em adição de
novas funcionalidades� Modificações em função de feedback dos usuários� Otimização� Treinamento dos usuários� Montagem da estrutura de suporte� Teste beta – Aceitação final
76
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPIterativo e Incremental� Cada iteração
�é planejada� realiza uma seqüência de atividades (de
elicitação de requisitos, análise e projeto, implementação, etc.) distintas
�geralmente resulta em uma versão executável do sistema
�é avaliada segundo critérios de sucesso previamente definidos
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPFluxos de Trabalho
� Modelagem de Negócio� Definição dos Processos e Modelo de Domínio
� Requisitos� Casos de Uso + Protótipo Interface com Usuário + Glossário
� Análise e Projeto� Desenvolvimento baseado em componentes. Mecanismos
de colaboração entre componentes de forma a realizar os cenários dos casos de uso
� Implementação� Produção de código e testes de unidade
� Testes� Testes do sistema, baseados nos casos de uso e demais
requisitos
77
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUP
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPGuiado por Casos de Uso� Os casos de uso não servem apenas para
definir os requisitos do sistema� Várias atividades do RUP são guiadas pelos
casos de uso:�planejamento das iterações �criação e validação do modelo de projeto�planejamento da integração do sistema�definição dos casos de teste
78
Prof. Marco Antônio Pereira Araújo, M.Sc. - Análise e Projeto de Sistemas Orientados à Objetos
RUPBaseado na Arquitetura� Arquitetura
� visão geral do sistema em termos dos seus subsistemas e como estes se relacionam
� A arquitetura é prototipada e definida logo nas primeiras iterações
� O desenvolvimento consiste em complementar a arquitetura
� A arquitetura serve para definir a organização da equipe de desenvolvimento e identificar oportunidades de reuso