Análise e Projeto Orientado a Objetos Aula 1 (Versão )

(1)

Histórico das Metodologias

Aula 1

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

( [email protected] )

( http://sites.google.com/site/professorgabrielbaptista )

Para começar!

• Horário – 19:15 às 23:00

• Intervalo – 20:50 às 21:15

• Avaliações:

[Soma da maiores notas (A1, A2, A3)] / 2 >= 6 A1 = Caso 1 + Caso 2 + Caso 3 + Caso 4 A2 = Integrada

A3 = Integrada

Análise e Projeto Orientado a Objetos - Professor Gabriel Baptista

Ementa do Curso

Apresentação da importância da modelagem no desenvolvimento de sistemas, histórico da evolução

das metodologias de modelagem, modelagem tradicional, estruturada e essencial. Modelagem

orientada a objeto, padrões e normas de UML, notação da interface, subtipos, composição e

agregação.

(2)

Objetivos do Curso

Desenvolver soluções através da Análise e Projeto Orientado a Objetos fazendo uso dos conceitos de UML.

Conteúdo Programático

• Histórico das metodologias de desenvolvimento de sistemas

• Conceitos de Orientação a Objetos

• Introdução à UML

• Os diagramas da UML

• Diagrama e Especificação de Casos de Uso

• Diagrama de Classes

• Diagrama de Sequência

• Diagrama de Atividades

• Diagrama de Máquina de Estados

• Diagrama de Componentes

• Diagrama de Implantação

Bibliografia Básica

BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML 2 – 2ª Edição. Rio de Janeiro: Campus, 2006.

BOOCK, Grady; JACOBSON, Ivar; RUMBAUGH, James. UML: guia do usuário. Rio de Janeiro:

Campus, 2006.

CARLSON, David. Modelagem de aplicações XML

com UML: aplicações práticas de e-business. São

Paulo: Pearson, 2002.

(3)

Bibliografia Complementar

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com

UML. 2ª ed. Rio de Janeiro: Elsevier, 2007.

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e

ao projeto orientado a objeto e ao desenvolvimento iterativo. 3ª ed. Porto

Alegre: Bookman, 2008.

OBJECT MANAGEMENT GROUP (OMG) – UML (UNIFIED MODELING LANGUAGE), UML Resource Page, em http://www.uml.org/, acessado em agosto de 2010.

SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison Wesley, 2007.

E agora?

O que vocês imaginam que irá acontecer após esta disciplina?

Relembrando...

Crise do Software – 1972 – Dijsktra:

De um desenvolvimento informal para atender à necessidades pessoais, passamos para um desenvolvimento corporativo, tendo

cada dia mais hardwares mais potentes.

(4)

Com isso:

• Custo acima do estipulado

• Diversos atrasos

• Funcionalidades abaixo do esperado

• Baixa qualidade

• Pessoas insatisfeitas

Solução Engenharia de Software

“Disciplina da engenharia que se ocupa de todos os aspectos da produção de

software”

(SOMMERVILLE, 2003)

Atividades fundamentais do Software

• Especificação: Definição de funcionalidades e restrições.

• Projeto (Desenho): Definição dos desenhos que servirão como auxílio para a produção do software.

• Implementação: Produção do software de acordo com o especificado / desenhado.

• Validação: Garantia que o software faz o que foi especificado.

• Evolução: Evolução natural para atender

às necessidades do cliente.

(5)

Quais os desafios enfrentados pela Engenharia de Software?

- Custo - Qualidade - Prazo - Pessoas - Funcionalidades

Análise e Projeto Orientado a Objetos - Professor Gabriel Baptista Custo

Qualidade

Prazo Pessoas

Funcionalidades

Metodologias para Análise e Projeto de Sistemas

• Análise Estruturada

• Análise Essencial

• Análise Orientada a Objetos

Análise Estruturada (Decomposição Funcional)

• Perspectiva das funções

• Apresentação dos processos

• Artefatos produzidos

 Diagrama de Entidade-Relacionamento

 Diagrama de Fluxo de Dados

 Dicionário de Dados

(6)

Análise Essencial (Lista de Eventos)

• Evolução da Análise Estruturada

• Preocupado com a questão de Controle

• Formado pelos modelos

 Ambiental (Contexto + Lista de Eventos)

 Comportamental (DFD + Dicionário)

 Informação (DER + Dicionário)

Análise Orientada a Objetos (Bottom-up)

• Enfoque nos dados

• Maior detalhe na modelagem

• Mais próximo da realidade

• Comunicação mais fácil com o usuário

Análise Orientada a Objetos

“O mundo real é composto por objetos. Cada objeto tem propriedades e comportamentos.

Então porquê não desenvolver programas que simulem no computador os objetos do mundo

real com suas propriedades e

comportamentos?”

(7)

Sistemas Orientados a Objetos

“Um sistema construído usando um método Orientado a Objetos é aquele cujos componentes são partes encapsuladas de dados e funções, que podem herdar atributos e comportamentos de outros componentes da

mesma natureza, e cujos componentes comunicam-se entre si por meio de

mensagens.”

(YOURDON)

Portanto...

Vantagens e Desvantagens

Vantagens

• Dependência menor entre os módulos de um sistema

• Combinação de estrutura (dados) e comportamento (funções) em um único objeto

• Compartilha comportamentos com objetos de níveis inferiores (herança)

• Ferramentas poderosas

• Reuso pode chegar a aumentar a produtividade Desvantagens

• Usuário se preocupa com funcionalidades

• Bancos de dados permanecem estruturados

(8)

O que vem a ser um objeto?

Qualquer coisa visível ou tangível para qual a ação, pensamento ou sentimento é direcionado, ou seja, o

mundo real é formado por coisas e para a Orientação a Objetos estas coisas são

denominadas de OBJETOS.

Os objetos são caracterizados por:

• Identidade

• Comportamento

• Estado

Sendo a comunicação entre os objetos feita através de MENSAGENS.

O que vem a ser uma classe?

Representação de um conjunto de objetos que possuem os atributos (propriedades) e comportamento (métodos) semelhantes.

Cada objeto criado a partir desta classe, pode ser chamado de instância da classe.

Classe professor instanciada para o Professor Gabriel

• Identidade

• RG: XX.XXX.XXX-X

• Comportamentos

• Lançar Nota

• Lançar Falta

• Estado

• Idade: 31

• Nome: Gabriel

• Disciplina que leciona: Análise e Projeto Orientado a Objetos

• Matrícula: XXXX

(9)

Obrigado!

Conceitos de Orientação a Objetos e Introdução à UML

Aula 2

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

( http://sites.google.com/site/professorgabrielbaptista ) Conteúdo adaptado do Material do Prof. Marcos Roberto e Silva

Revisando

• O que significa modelar um sistema?

• O que é a Engenharia de Software?

• Quais os desafios enfrentados pela Engenharia de Software?

• O que trata a Crise do Software?

• Quais são as atividades essenciais para o desenvolvimento de um software?

• Quais foram as metodologias para Análise e Projeto de Sistemas que foram apresentadas? No que elas se diferem?

(10)

Princípios da Orientação a Objetos

“A análise orientada a objetos baseia-se em alguns princípios que são utilizados para administrar a complexidade e facilitar a Análise e Projeto Orientado

a Objetos”

Estes princípios são:

• Abstração

• Herança

• Encapsulamento

• Polimorfismo

Vocês sabem dizer o que significa cada um destes princípios?

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.”

(Dictionary of Computing. Oxford University Press, 1986)

Quais serão os objetos relevantes para desenvolver um sistema de sala de aula?

Herança

O conceito de HERANÇA representa GENERALIZAÇÃO e ESPECIALIZAÇÃO, tornando explícitos os atributos e métodos comuns em uma hierarquia de classe.

Existem dois tipos de herança

• Simples

• Múltipla

(11)

Ainda dentro da sala de aula

Tanto professor como aluno são pessoas, que tem nome, RG e idade.

Sobre a Herança

• Generalização (Superclasse)

• Especialização (Subclasse)

É possível adicionar novos métodos e/ou reescrever métodos existentes em uma subclasse.

Encapsulamento

• Ocultação de características e comportamentos

• Proteção de dados

• Com isso temos:

• Propriedades Privadas

• Propriedades Públicas

• Métodos Privados

• Métodos Públicos

• As mensagens entre os objetos serão trafegadas somente entre métodos e propriedades públicos

(12)

Polimorfismo

“É o princípio em que classes derivadas (subclasses) de uma mesma superclasse podem invocar operações que têm a mesma

assinatura (nome), mas comportamentos diferentes em cada subclasse, produzindo resultados diferentes, dependendo de como

cada objeto implementa a operação.”

(Marcos Roberto e Silva)

Polimorfismo

Obrigado!

(13)

Introdução à UML

Aula 3

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

Obrigado!

Conceitos de Orientação a Objetos e Introdução à UML

Aula 2

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

(14)

Revisando

• O que significa modelar um sistema?

• O que é a Engenharia de Software?

• Quais os desafios enfrentados pela Engenharia de Software?

• O que trata a Crise do Software?

• Quais são as atividades essenciais para o desenvolvimento de um software?

• Quais foram as metodologias para Análise e Projeto de Sistemas que foram apresentadas? No que elas se diferem?

Revisando

• Qual o conceito de objeto?

• Qual o conceito de classe?

• Qual o conceito de instância?

• Qual o conceito de abstração?

• Qual o conceito de herança?

• Qual o conceito de encapsulamento?

• Qual o conceito de polimorfismo?

Histórico

• Orientação a objetos é um paradigma abordado desde a década de 80!

• Inúmeras metodologias

• OMT, Rumbaugh

• COAD/YOURDON, Coad-Yourdon,

• OOSE, Jacobson,

• SHLAER/MELLOR, Shlaer-Mellor,

• BOOCH, Grady Booch

(15)

Histórico

• UML – Unified Modeling Language

• Padronizada pela OMG: Object Management Group

• Os três amigos: Rumbaugh, Jacobson e Booch

• Versão 2.0

Sobre a UML

“(UML®) helps you specify, visualize, and document models of

software systems, including their structure and design, in a way that

meets all of these requirements”

http://www.omg.org/gettingstarted/what_is_uml.htm

UML

• Linguagem

• Linguagem para visualização

• Linguagem para especificação

• Linguagem para construção

• Linguagem para documentação:

Requisitos, arquitetura, desenho, código fonte, planos de projeto, testes, protótipos, releases.

(16)

UML 2.0

• 13 Diagramas:

 Estrutura: Classe, Objetos, Componente, Estrutura Composta, Pacote e Distribuição (Implantação).

 Comportamento: Caso de Uso, Atividade, Máquina de Estado.

 Interação: Seqüência, Comunicação, Temporização e Interação.

Diagrama de Classes

• Conjunto de classes, interfaces e colaborações, apresentando seus relacionamentos.

• Diagrama mais comum da OO.

• Visão estática da arquitetura do sistema.

Diagrama de Classes

(17)

Diagrama de Objetos

• Conjunto de componentes e seus relacionamentos.

• Apresenta uma visão dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento de execução de um processo do software.

Diagrama de Objetos

Diagrama de Componentes

• Partes internas, conectores e portas que implementam um componente.

• Ao instanciar um componente, suas partes internas também são instanciadas.

• Está associado à linguagem de programação que será utilizada no desenvolvimento do sistema.

(18)

Diagrama de Componentes

Diagrama de Estrutura Composta

• Estrutura interna de uma classe ou colaboração.

• Segundo os três amigos, a diferença entre este diagrama e o diagrama de componentes é muito pequena.

Diagrama de Pacotes

• Decomposição do modelo dentro da organização e suas dependências.

• Um pacote pode ter qualquer

diagrama da UML.

(19)

Diagrama de Pacotes

Diagrama de Distribuição

• Configuração dos nós e os componentes que vivem em cada um destes pontos.

• Visão estática da arquitetura.

Diagrama de Distribuição

(20)

Diagrama de Caso de Uso

• Conjunto de casos de uso e atores (tipo especial de classe) e seu relacionamento.

• Visão de uso estática do sistema.

• Modelagem do comportamento do sistema.

Diagrama de Caso de Uso

Diagrama de Atividade

• Estrutura do processo.

• Passo a passo da execução.

• Visão dinâmica do sistema.

(21)

Diagrama de Atividade

Diagrama de Máquina de Estado

• Estado, transições, eventos e atividades.

• Visão dinâmica de um objeto.

• Modelagem do comportamento de uma interface, classe ou colaboração.

Diagrama de Máquina de Estado

Análise e Projeto Orientado a Objetos - Professor Gabriel Baptista http://www.wthreex.com

(22)

Diagrama de Seqüência

• Diagrama de Interação

• Enfatiza a cronologia de troca de mensagens entre classes.

Diagrama de Seqüência

Análise e Projeto Orientado a Objetos - Professor Gabriel Baptista http://www.wthreex.com

Diagrama de Comunicação

• Diagrama de Interação

• Enfatiza a organização estrutural

dos objetos e papéis que enviam e

recebem mensagens.

(23)

Diagrama de Comunicação

Análise e Projeto Orientado a Objetos - Professor Gabriel Baptista http://www.novatec.com.br

Diagrama de Temporização

• Apresenta momento atual em relação a diferentes objetos e papéis, em contrapartida a somente seqüências de mensagem relativas.

Diagrama de Temporização

(24)

Diagrama de Interação

• Diagrama híbrido composto pelos diagramas de atividade e seqüência.

Diagrama de Interação

Hierarquia dos diagramas

(25)

Obrigado!

Requisitos

Aula 4

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

Um pouco de reflexão:

(26)

Acabou aí?

Tem mais?

Mas na verdade...

(27)

Isto é comum?

SIM!!!

• Em 1995, um relatório elaborado pelo Grupo Standish*, chamado CHAOS, alertou que apenas 16,2% dos projetos eram encerrados com sucesso.

• O mesmo estudo em 2009 apresentou uma melhoria no índice, passando para 32%.

• Na verdade, fala-se em crise do software desde 1968!

* 1995. Acessado através de http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

Relatório do Grupo Standish CHAOS - 2011

- 37% dos projetos de software com sucesso;

- 42% atrasados, acima do custo, e/ou com menos funcionalidades;

- 21% cancelados ou nunca usados.

Isto é comum?

Segundo Capers Jones and Bill Curtis:

- 25% dos projetos de software falham ou são abandonados;

- 15% dos defeitos permanecem no produto entregue ao cliente;

- 30% a 44% do tempo está sendo utilizado para retrabalho nas companhias (tempo não produtivo);

- 50% dos prazos são atendidos pelas companhias.

Segundo Professor Dr. Ivanir Costa:

- 65% dos erros ocorrem na fase de requisitos - 8% dos erros ocorrem na fase da codificação*

* Testes caixas pretas só conseguem verificar estes erros

(28)

A questão é... Por quê?

Para Jack Ganssle:

• Let's face it: any idiot can write code.

Estudo do Grupo Standish:

• Falta de Envolvimento do Usuário

• Falta de Gerenciamento

• Falta de necessidades claras

A questão é... Por quê?

Segundo Humphrey*:

- Cronogramas fora da realidade - Equipe inapropriada

- Mudanças de Necessidades - Trabalho com baixa qualidade - Crenças em mágica

* Maio de 2002. Acessado através de www.computerworld.com

Agora imaginem...

Um idiota programando + Lista de necessidades confusas ou inexistentes + Necessidades sendo modificadas a toda hora __________________________________________

CAOS

(29)

Existe algo a ser feito?

Engenharia de Requisitos

“A Engenharia de Requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar

para resolver. Ela inclui o conjunto de tarefas que elevam a um entendimento de

qual será o impacto do software sobre o negócio, do que o cliente quer e de como

os usuários finais vão interagir com o software”

* Pressman, 2006

Engenharia de Requisitos O que é um requisito?

“Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e

definem restrições sobre sua operação e implementação”

* Sommerville, 2005

(30)

Engenharia de Requisitos Tipos de requisitos

- Requisitos do usuário

- Funções que o sistema deve ter, visualizados de uma maneira simples

- Requisitos do sistema

- Domínio: Leis, normas ou até mesmo uma restrição funcional obtidos a partir das necessidades específicas do sistema.

- Funcionais: Funcionalidades ou os serviços que se espera que o sistema forneça.

- Não-funcionais: Não dizem respeito diretamente às funções específicas do sistema. Definem atributos como confiabilidade e restrições.

* Sommerville, 2005

Engenharia de Requisitos

Análise e Projeto Orientado a Objetos - Professor Gabriel Baptista Engenharia de Requisitos

Desenvolvimento de Requisitos Gerenciamento de Requisitos

Elicitação Análise Especificação Validação

* Costa, 2007: Sub-Componentes do domínio da Engenharia de Requisitos

Desenvolvimento de Requisitos Elicitação

“Vamos tentar extrair as necessidades do cliente...”

- Introspecção (Imaginação) - Questionários

- Entrevistas

- Etnografia (Observação)

- JAD (Joint Application Development)

(31)

Desenvolvimento de Requisitos Análise

“Vamos pensar sobre tudo que foi levantado e, de alguma maneira, vamos documentar

estas necessidades na forma de sistema...”

- JAD (Joint Application Development) - Use cases

- Prototipação

Desenvolvimento de Requisitos Especificação

“Vamos criar um contrato com o nosso cliente...”

- O objetivo é gerar um documento que possa ser lido por diversos stakeholders:

- Clientes - Gerentes

- Engenheiros de Desenvolvimento - Engenheiros de Teste

- Engenheiros de Implantação

* Sommerville, 2005

Desenvolvimento de Requisitos

Especificação

(32)

Desenvolvimento de Requisitos Validação

“Vamos confirmar o que o foi pedido pelo cliente...”

- Prototipação - Revisões formais

Desenvolvimento de Requisitos

* Costa, 2007: Desenvolvimento de requisitos em um processo iterativo

Obrigado!

(33)

Modelo de Caso de Uso

Aula 5

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

Revisando

• O que significa UML?

• Qual o objetivo da UML?

• Quantos diagramas compõe a UML?

• Que tipo de representação pode ser feita através dos diagramas da UML?

• Quais são as etapas básicas para o desenvolvimento de requisitos?

Como começar?

Detectando as necessidades do

sistema!

(34)

Modelo de Caso de Uso

• Uma das maneiras utilizadas para desenvolvimento dos requisitos funcionais.

• Composto por:

• Diagrama

• Especificação

Para que serve?

• Entender o comportamento do sistema

• Identificar as funcionalidades de arquitetura

• Localizar as classes

• Identificar casos de teste

• Planejamento

• Criação de manuais

Caso de Uso

“O modelo de casos de uso é um modelo das funções pretendidas do sistema e seu ambiente, e serve como um contrato estabelecido entre o cliente

e os desenvolvedores. O modelo de casos de uso é usado como fonte de informações essencial para atividades

de análise, design e teste.”

http://www.wthreex.com/rup/

(35)

Diagrama de Caso de Uso

Exemplo de diagrama de Caso de Uso

Ator

“Um ator define um conjunto coerente de papéis que os usuários do sistema podem desempenhar ao interagir com ele. Uma instância de

ator pode ser desempenhada tanto por um indivíduo quanto por um

sistema externo.”

http://www.wthreex.com/rup/

(36)

Caso de Uso

“Um caso de uso define um conjunto de instâncias de casos de uso, no

qual cada instância é uma seqüência de ações realizadas por

um sistema que produz um resultado de valor observável para

determinado ator.”

http://www.wthreex.com/rup/

Relacionamentos existentes

• Associação

• Generalização (Herança)

• Inclusão

• Extensão

Generalização

• Conceito de Herança

• Pode ser aplicado no caso de uso e no ator

(37)

Inclusão

• Ação do sistema que será executada por mais de um caso de uso.

• A seta é direcionada para o caso de uso que será incluído.

Inclusão

Extensão

• Ação do sistema que pode ser executada por mais de um caso de uso.

• A seta é direcionada para o caso de uso que poderá executar o caso de uso opcional.

(38)

Extensão

Especificação do Caso de Uso

• Número: Número identificador do UC

• Nome: Nome dado ao UC no diagrama

• Breve descrição: Descrição em um parágrafo falando sobre o UC

• Pré-condições: O que deve acontecer antes do caso de uso ser executado.

• Fluxo de eventos: Fluxo básico (principal ou happy day), Fluxos alternativos, Fluxos de exceção)

• Requisitos Especiais: Alguma informação adicional que deva ser comentada

• Pós-condições: O que deve acontece após o caso de uso executar.

• Inclusões: Pontos de inclusão

• Extensões: Pontos de extensão

• Relacionamentos: Atores relacionados, UC’s de especialização ou generalização.

Como fazer?

1.Identificar possíveis atores.

2.Identificar possíveis ações do sistema.

3.Criar diagrama apontando relacionamento dos elementos.

4.Criar especificação de cada um dos casos

de uso levantados.

(39)

Obrigado!

Diagrama de Classes

Aula 6

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

Revisando

• Qual o objetivo do Modelo de Caso de Uso?

• O que o ator representa em um diagrama de caso de uso?

• O que o caso de uso representa em um diagrama de caso de uso?

• Qual o objetivo do relacionamento de herança?

• Qual o objetivo do relacionamento de inclusão?

• Qual o objetivo do relacionamento de extensão?

(40)

Diagrama de Classes

• Representação estática / estrutural do sistema.

• Entidades essenciais.

• Principal e mais usado diagrama da UML.

Classe

• Representação de um conjunto de objetos que possuem os atributos (propriedades) e comportamento (métodos) semelhantes.

• Cada objeto criado a partir desta classe, pode ser chamado de instância da classe.

O que representamos em uma classe?

• Atributos

• Métodos

• Visibilidade

• Privada (-)

• Pública (+)

• Protegida (#)

• Pacote (~)

(41)

Relacionamento entre classes

Associação

• Nome e direção

• Multiplicidade

• Navegabilidade

• Papéis

• Restrições

Prof. Marcos Roberto e Silva

Tipos de associação

• Unária

• Binária

• Agregação

• Composição

• Generalização

• Dependência

Associação Unária

• Auto-relacionamento

(42)

Associação Binária

• Relacionamento simples

Agregação

• Funcionam como uma entidade única

• Possui um objeto controlador (todo) que cuida dos objetos agregados (partes)

• Os objetos “partes” podem existir sem o objeto “todo”

Agregação

(43)

Composição

• Um objeto “parte” pertence somente a UM objeto “todo”

• Os objetos “partes” não podem existir sem o objeto “todo”

Composição

Generalização

• Aplicação do conceito de herança

• É possível representar uma herança múltipla

• Representa relacionamentos do tipo “É

UM”.

(44)

Generalização

Dependência

• Indica grau de dependência entre classes

• Relacionamentos de dependência podem expressar também ordem de precedência, onde um elemento deve preceder a outro.

Dependência

(45)

Passos para modelar um diagrama de classes

1. Identificar as classes baseada nos casos de uso.

2. Identificar os atributos das classes. (sem levar em conta suas visibilidades ou tipos)

3. Analisar os atributos, identificando se alguns deles são na realidade relacionamentos.

4. Algumas operações podem ser identificadas neste ponto, mas com certeza, não todas. As operações em geral são descobertas com o auxílio de outros diagramas.

5. Analisar classes semelhantes, remodelando as com relacionamentos de Herança.

6. Lançar detalhes dos atributos.

Obrigado!

Diagrama de Sequência

Aula 7

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

(46)

Para que serve?

Utilizado para determinar a ordem das mensagens trocadas entre papéis e

objetos, com base no tempo.

Quais são os componentes deste diagrama?

Estereótipos de Objetos

(47)

Exemplo

Portanto

• A sequência é dada desde a interação do ator com o sistema.

ATOR -> INTERFACE -> CONTROLE -> CLASSES

• Não se faz necessário apontar o retorno das mensagens

• A condicional existe através de um bloco do tipo “OPT”.

• É possível enviar mensagens de criação e destruição de objetos durante a sequência do diagrama.

Obrigado!

(48)

Diagrama de Atividades

Aula 08

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

Para que serve?

• Determinação de fluxo

• Atividades em um processamento

• Trabalho entre as unidades organizacionais em um modelo de negócio.

• Cenários dos casos de uso

Quais são os componentes deste diagrama?

Atividade

Decisão Início Transição

Bifurcação

Junção Fim

Áreas organizacionais

(49)

Exemplo

Obrigado!

Diagrama de Máquina de Estados

Aula 09

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

(50)

Para que serve?

• Modelar o comportamento de um objeto individualmente.

• Descrever a seqüência de estados que um objeto possui durante o seu ciclo de vida.

• Modelar aspectos dinâmicos do sistema.

O que significa estado?

“Período de tempo em que o objeto atenda a uma condição, realize alguma atividade ou

espere algum evento.”

Quando usar?

• Comportamentos que respondam à mensagens assíncronas

• Comportamentos que dependam do

comportamento anterior para funcionar.

(51)

deste diagrama?

Exemplo – Caixa eletrônico

Obrigado!

(52)

Diagrama de Componentes

Aula 10

(Versão 2013-02)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

Projeto com reuso

“O processo de projeto, na maioria das disciplinas de

engenharia, baseia-se no reuso de sistemas existentes ou componentes”

(SOMMERVILLE, 2008)

Projeto com reuso

• Preocupação desde os requisitos com os pontos do projeto que podem ou serão potenciais itens de reuso.

• Dependente de um processo de

desenvolvimento voltado para tal tarefa.

• Custo inicial pode ser mais alto, entretanto,

o retorno do investimento vai acontecer à

medida que o componente for reutilizado.

(53)

Projeto com reuso

Desenvolvimento sem reuso

Desenvolvimento com reuso

(54)

Vantagens do reuso

• Confiança aumentada

• Risco de processo reduzido

• Uso eficiente de especialistas

• Conformidade com padrões

• Desenvolvimento acelerado

Desvantagens do reuso

• Falta de apoio de ferramenta

• Síndrome do não-inventado-aqui

• Criação e manutenção de uma biblioteca de componentes

Abordagens que apoiam o reuso

• Bibliotecas

• Frameworks

• Softwares de prateleira

• Desenvolvimento orientado a objetos

• Desenvolvimento orientado a serviços

• Desenvolvimento orientado a aspectos

• Design patterns

Em resumo: Componentização

(55)

O que significa componente?

“Parte lógica e substituível de um sistema que atende e provém a realização de um conjunto

de interfaces.”

UML – Diagrama de Componentes

Para que serve?

• Modelar os componentes existentes no sistema, bem como o relacionamento entre eles através de interfaces.

O que significa interface?

“Coleção de operações que especificam um serviço que é provido ou é requerido por uma

classe ou componente.”

(56)

componentes?

• Descrição de componentes do sistema.

• Representação explícita de uma biblioteca comum entre diversas aplicações

Quais são os componentes deste diagrama?

Exemplo – Caixa eletrônico

(57)

Exemplo – Caixa eletrônico

Obrigado!

Diagrama de Implantação

Aula 11

(Versão 2013-1)

Análise e Projeto Orientado a Objetos

Professor Gabriel Baptista

(58)

implantação?

• Representar a relação entre diferentes hardwares existentes no sistema.

• Organizar distribuição de arquivos entregáveis (executáveis, bibliotecas, bases de dados).

Componentes do diagrama

Exemplo – Caixa eletrônico

(59)

Obrigado!