An_liseeprojetodesistemasorientadosaobjetos-notasdeaula

Análise e projeto de sistemas com orientação a objetos Notas de aula

Elaboração: Prof.: José Luiz Rodrigues Junior [email protected]

Ciência da computação – Análise e projeto de sistemas com orientação a objetos 5º Semestre - Professor: José Luiz Rodrigues Junior

Novembro de 11

2


Novembro de 11

2

Índice 1 – ORIENTAÇÃO A OBJETOS.................................................................................................... 3 1.1 – Alavancas da orientação a objetos....................... .............................................. ................................... .................. ........... .....3 3 1.2 – Benefícios da OO.................... ........................................... .............................................. .............................................. ............................. ......3 3

2 – DEFINIÇÕES .................................................................................................................... 5 2.1 - Objeto Objeto....................... ............................................. ............................................. .............................................. ............................................ .......................5

ESTADO....................... .............................................. .............................................. ........................................... .......................... ............ ............ ............ ...... 6 COMPORTAMENTO....................... .............................................. .............................................. .............................. ............. ............ ........ 6

2.2 - Mensagem...................... ............................................. .............................................. .......................................... ......................... ............ ............ ........6 2.3 - Operações .........................................................................................................8 ......................................................................................................... 8 2.4 – Método ..............................................................................................................8 .............................................................................................................. 8 2.5 - Herança .................................. ........... .............................................. ............................................. ............................................. ............................. ......8 8 2.6 – Polimorfismo...................... ............................................. .............................................. ....................................... ...................... ............ ........... .....9 9

3 – MODELO DE OBJETOS...................................................................................................... 10 3.1 - Abstração....................... .............................................. .............................................. ........................................... ......................... ........... ........... .....10 10 3.2 - Encapsulamento...................... ............................................. .............................................. ................................. ................ ............ ........ ..10 10 ................................................................................................................................. 11 3.3 – Modularidade..................... ............................................ .............................................. ........................................ ....................... ............ ......... ...11 11 3.4 – Hierarquia...................... ............................................. .............................................. .............................................. ............................ ........... ........12 3.5 - Benefícios do modelo de objetos objetos....................... ............................................ ........................... ............ ............ ............ ........ ..12 12

4 – CLASSES....................................................................................................................... 14 4.1 – Definição ........................................................................................................14 ........................................................................................................ 14 4.2 – Exemplos de classe: classe:....................... .............................................. .............................................. ....................................... ..................... .....14 14 ................................................................................................................................. 15 ................................................................................................................................. 15 ................................................................................................................................ 15 4.3 – Classes e visões..................... ............................................ .............................................. ................................. ................ ............ ............ ......15 15 ................................................................................................................................. 16 4.4 - Classes – Classificação e instanciação...................... ........................................... ........................... ............ ............ ......17 17 4.5 – Classes – Generalização / Especialização ...................... ............................................. ................................. ............17

.............................................................................................................................. 17 4.5.1 – Considerações....................... .............................................. .............................................. ............................... .............. ............ ......... ... 18

4.6 - Herança....................... .............................................. .............................................. .............................................. ........................................ .................18 18 4.7 – Composição por agregação..................... ............................................ .............................................. ................................ ........... ..19 19 4.8 – Composição.................... ........................................... .............................................. .............................................. ............................. ............ ........19 4.9 – Classes abstratas....................... .............................................. .............................................. .................................... ................... ........... .....20 20 4.10 – Relacionamentos ............................................................................................21 ............................................................................................ 21 4.11 – Polimorfismo..................... ............................................ .............................................. .................................... ................... ............ ............ ......21 21

5 – MÉTODOS PARA ANÁLISE COM ORIENTAÇÃO A OBJETOS......................................................... .........................................................23 23 5.1 – O método BOOCH...................... ............................................. .............................................. .......................................... ........................ .....23 23 5.2 – O método OMT (Object Modeling Techinique).................... ............................ .............. ............ ............ ........ ..24 24 5.3 – O método OOSE (Object-Oriented Software Engeneering) ..................... ........................... ......... ...24 24

6 – UML – U NIFIED MODELING LANGUAGE.......................................................................... 25 7 – VISÕES EM UML.......................................................................................................... 25 8 – DIAGRAMAS DA UML........................................ ................................................................................. ............................................................ ................... 27 8.1 – Diagrama de casos de uso ............................................................................... 28

8.1.1 – Simbologia para diagramas de casos de uso..................... ........................................ ......................... ........ 29 .............................................................................................................................. 29


8.1.2 – Interações em casos de uso....................... .............................................. .............................................. ........................... .... 29 8.2 – Diagrama de classes..................... ............................................ .............................................. .......................................... ...................... ...31 31

8.2.1 – Simbologia..................... ............................................ .............................................. ......................................... ........................ ............ ...... 31 8.2.2 – Classes Classes e domínio domínio do problema .................... ........................................... ...................................... .................... ....... 32 8.2.3 – Relacionamento entre classes.................... ........................................... ......................................... ........................ .......... 32 8.2.3.1 – Cardinalidade / Multiplicidade.................... ........................................... ............................... .............. ......... ... 34 8.3 – Diagrama de sequência ...................................................................................35 ................................................................................... 35

8.3.1 - Simbologia.................... ........................................... .............................................. .............................................. ................................ ......... 35

8.4 – Diagrama de colaboração..................... ............................................ .............................................. ............................. ............ ........39 8.5 – Diagrama Diagrama de Atividades....................... .............................................. ........................................ ....................... ............ ............ ........39

8.5.1 - Simbologia.................... ........................................... .............................................. .............................................. ................................ ......... 40 8.5.2 - Raias..................... ............................................ .............................................. .............................................. .............................. ............. .......... .... 41 ................................................................................................................................. 41 8.6 – Diagrama de estados...................... ............................................. .............................................. ................................. ................ .......... ....42 42

8.6.1 - Simbologia ................................................................................................ 42 8.6.2 - Evento...................... ............................................. .............................................. .............................................. ..................................... .............. 42 ................................................................................................................................. 43

8.6.3 – Transição...................... ............................................. .............................................. .............................................. ................................ ......... 44

8.7 – Diagrama de componentes ..............................................................................44 .............................................................................. 44 ................................................................................................................................ 46 8.8 – Diagrama de implantação (Ou disponibilidade)..................... ............................. .............. ............ ........... .....47 47

9 – BIBLIOGRAFIA................................................................................................................ 48

2


1 – Orientação a objetos O termo Orientação a Objetos significa organizar o mundo real como uma coleção de objetos. Dos Dos objet objetos os nos nos inte interes ressa sa a sua sua Estrutura de Dados e um

Conjunto de Operações (Métodos). Os objetos, a sua estrutura de dados e o conjunto de operações são selecionados de acordo com objetivos bem estabelecidos. Ao modelar uma empresa, o analista deve identificar seus tipos de objetos, seus eventos, as operações (métodos) que levam esses objetos objetos a comportar-se comportar-se de uma certa forma, e as regras que governam essa essass oper operaç açõe ões. s. Os sist sistema emass devem devem ser ser visu visual aliza izado doss co como mo uma uma coleção de objetos e não como um conjunto de programas. A Orientação a Objetos não é um conceito novo. Já era utilizado, em pelo menos três áreas, há duas décadas. décadas. Permite maior velocidade velocidade de Desenvolvimento. Linguagens de Programação com orientação a objetos: Simula Smalltalk Objective C C++ JAVA

1.1 – Alavancas da orientação a objetos Evolução Tecnológica Distribuição de Processamento Tecnologia Cliente-Servidor Internet Java Aplicações WEB

1.2 – Benefícios da OO Reaproveitamento Estabilidade

3


Projetista pensa em termos de comportamento dos objetos e não em detalhes de baixo nível Construção de objetos cada vez mais complexos Confiabilidade Verificação de Precisão - testes Desenvolvimento Acelerado Integridade Programação Facilitada Manutenção Facilitada Ciclo de Vida Dinâmico Refinamento Durante a Construção Modelagem Mais Realista Melhor Comunicação entre Profissionais de Sistema e Clientes Interoperabilidade Processamento Cliente-Servidor Processamento Distribuído e em Paralelo Bibliotecas de Classes Industrializadas e Corporativas

4


Análise e projeto de sistemas orientados a objetos

2 – Definições 2.1 - Objeto Um objeto existe no mundo real e é um elemento que podemos manipular,

acompanhar seu comportamento, criar, destruir, etc.

Existem também objetos que não encontramos no mundo real, mas que podem ser derivados da estrutura de outros objetos do mundo real. Todo objeto é uma entidade concreta, apesar de sua concepção ser abstrata. Pode-se também definir um objeto da seguinte maneira:

“um objeto é uma abstração de um conjunto de coisas do mundo real, sendo que: todas as coisas do mundo real em um conjunto - as instâncias - têm as mesmas características. Todas as instâncias são sujeitas e em conformidade às mesmas regras” “...um objeto representa uma entidade, item ou unidade individual, identificável, sendo real ou abstrato, com regras bem definidas no domínio do problema." Em processamento de dados, um objeto tenta unir o que até então era tratado de forma separada : DADOS e FUNÇÕES

.

Os objetos são agrupamentos de características e ações pertencentes a uma entidade. Suas características são representadas através dos atributos e suas ações são representadas pelos métodos que ela venha a possuir. O conjunto de atributos e métodos é que compõem um objeto.

Exemplos de objetos: Coisas tangíveis :

Mesa, Cadeira, Pessoa, empresa, País,

:

Qualquer evento ou ocorrência (Copa

Etc..

Incidentes do Mundo)

5


:

Interações

Transações (Caixa eletrônico)

Todo objeto possui três características básicas:

ESTADO Considera-se o estado de um objeto os valores dos atributos e o status das operações que o objeto executou.

COMPORTAMENTO As operações, existentes nos métodos, definem o

comportamento do objeto, que é a forma como um objeto age e reage em termos de mudanças de estado e respostas às operações que sabe executar. Pode-se definir um objeto como abaixo:

IDENTIDADE Identidade é a propriedade de um objeto que o distingue

de

todos

os

demais

objetos.

Um

identificador é anexado ao objeto no momento da sua criação e permanece com ele por toda sua existência, sendo que nenhum outro objeto poderá possuir identidade semelhante.

2.2 - Mensagem Um objeto não existe isoladamente. Ele pode interagir com outros objetos, atuando sobre estes, ou sofrendo ação dos mesmos. Para que os objetos possam se comunicar, ou qualquer outra interface possa se comunicar com um objeto, é necessário que exista um tipo de protocolo para que possam se entender. Dá-se a essa comunicação o nome de mensagem . Toda mensagem deve ser composta pelos seguintes itens:

Identificador Nome do objeto que será alvo da mensagem.

6


Método Nome do método que se deseja executar no objeto alvo.

Argumentos Informações suplementares para que o método possa ser excutado.

7


2.3 - Operações Uma operação pode ser descrita como sendo um serviço ou comportamento resultante de um procedimento algorítmico. Existe uma diferença entre operação e método: Uma operação é algo invocado por um objeto, enquanto método é o corpo do procedimento. Existem quatro tipos de operações que podem ser realizadas sobre um objeto:

Construtoras Geração de um novo Objeto da Classe (instanciação)

Seletoras Recuperação do conteúdo dos atributos de um Objeto, sem alterá-los

Modificadoras Alteração do valor dos atributos ou estado de um Objeto

Destrutoras Eliminação de um objeto existente

2.4 – Método Conjunto de instruções associado com a operação de uma classe, propiciando comportamento aos objetos da Classe. Invocado somente por meio de passagem de mensagens por: Objetos de outras Classes Interface de usuário Lógica do programa

2.5 - Herança

É o compartilhamento de atributos e operações entre objetos situados em diferentes níveis hierárquicos. Como o

8


assunto

é

complexo,

ele

será

tratado

com

mais

propriedade em capítulo à parte.

2.6 – Polimorfismo Significa que diferentes tipos de objetos podem responder a uma mesma mensagem de maneiras diferentes. Pode-se declarar funções e procedimentos com os mesmos nomes, enquanto suas chamadas possam a ser distintas pelos seus parâmetros de retorno, consistindo do número dos seus argumentos e dos seus tipos de valores de retorno.

9


3 – Modelo de objetos Diferentes metodologias permitem diferentes abordagens para a resolução de um problema. Em orientação a objetos, existe o conceito de “modelo de objetos” que é composto de 4 elementos básicos:

3.1 - Abstração Denota as características essenciais de um objeto que o distinguem de todos os outros tipos de objetos e portanto definem nitidamente os limites conceituais relativos à perspectiva do observador.

Descreve as características

visíveis do objeto. Tem seu foco no comportamento observável do objeto. Não descreve, entretanto:

A sua implementação O seu funcionamento

3.2 - Encapsulamento É o processo de identificação dos elementos de uma abstração que constituem sua estrutura e comportamento. Constitui em esconder todos os detalhes de um objeto que não contribuem para suas características essenciais. É uma técnica utilizada para proteger informações onde o acesso aos dados do objeto é feito através da chamada a uma operação da sua interface.

Benefícios: Segurança Protege os atributos dos objetos de terem seus valores corrompidos por outros objetos.

Independência “Escondendo” seus atributos, um objeto protege outros objetos de complicações de dependência de sua estrutura interna.

10


O encapsulamento esconde os detalhes de implementação de um objeto

3.3 – Modularidade A modularidade consiste na divisão do sistema em componentes individuais fazendo com que o problema apresente

maior

clareza e

compreensão,

além de

identificar os limites do sistema e dos seus programas. Uma outra definição de modularidade é :

11


“Modularidade é a propriedade de um sistema de ser decomposto em um conjunto de módulos coesivos e relacionalmente desprendidos.”

3.4 – Hierarquia Um grupo de abstrações frequentemente forma uma hierarquia e com a identificação dessas hierarquias no projeto, pode-se simplificar o entendimento do problema. Pode-se definir hierarquia como segue:

“Hierarquia é uma graduação ou ordenamento de abstrações “

3.5 - Benefícios do modelo de objetos É adequado para sistemas que pretendem evoluir com o tempo, pois sua estrutura permite que se mude a implementação interna de um objeto sem ter que mudar todo o código que se situa acima deste. É um modelo maleável, o que permite a inserção de novas características.

12


Princípios como “esconder informações” e “modularidade” permitem

facilidade

manutenção constante.

13

em

sistemas

que

possuem


4 – Classes 4.1 – Definição Todos os objetos estão armazenados em estruturas que identificam os seus atributos e os seus métodos. Analogamente às tabelas, dos bancos de dados relacionais, onde os comandos DDL (Em SQL) permitem a criação de sua estrutura, as classes, em orientação a objetos, propiciam a montagem da estrutura dos objetos que a comporão. As classes são estruturas genéricas de onde os objetos podem derivar. Cada objeto é uma linha de vida à parte e cada um possui um estado específico, sendo que cada objeto é diferente do outro (Em seu conteúdo e estado) mesmo que a sua interface seja a mesma.

“Uma classe é um grupo de objetos que compartilham uma estrutura comum e um comportamento comum”

4.2 – Exemplos de classe: Existem vários tipos de objetos, portanto existem tipos de classes:

14

vários


Graficamente,

podemos

representar

uma

classe da

seguinte forma:

CONTA CONTA

Classe

Titular Titular Número Número Saldo Saldo

Atributos

Depósito( ) Saque( ) Transferância( )

Métodos

- Todos os objetos são instâncias de uma classe. - Classe é o que se projeta e programa - Objeto é o que se cria durante o processamento

4.3 – Classes e visões A interface de uma classe provê a visão externa, e portanto, enfatiza a abstração enquanto esconde sua estrutura e segredos de seu comportamento. A implementação de uma classe é sua visão interna , que engloba os segredos de seu comportamento. A interface de uma classe divide-se em:

Pública (Representada pelo símbolo “+”) Uma declaração que forma parte da interface de uma classe e é visível para todos os clientes que são habilitados para isto;

Protegida (Representada pelo símbolo “#”

15


Uma declaração que forma parte da interface de uma classe, mas não é visível para quaisquer

outras

classes,

exceto

suas

subclasses;

Privada (Representada pelo símbolo “-”) Uma declaração que forma parte da interface de uma classe, mas não é visível para quaisquer outras classes.

16


4.4 - Classes – Classificação e instanciação Classificação É a operação que divide em uma ou mais categorias (classes) indivíduos dentro de um domínio;

Instanciação É a operação que evidencia um indivíduo (Objeto) que pertence a uma categoria. São operações opostas. Quando se une vários indivíduos em uma categoria, é uma classificação, mas quando se pega um único indivíduo da categoria, é uma instanciação.

4.5 – Classes – Generalização / Especialização Generalização Ato de definir-se uma Classe (supertipo) que irá conter as características e o comportamento que outras Classes possuem em comum;

Especialização Ato de definir-se uma Classe que além de herdar as características e o comportamento do Supertipo ainda possui outras características que são sua especialidade (somente ela tem) e, portanto, os demais subtipos não possuem

17


E s p e c i a l i z a ç ã o

G e n e r a l i z a ç ã o

4.5.1 – Considerações Uma Classe derivada herda a estrutura de dados e métodos

de

sua

classe

“base”,

mas

pode

seletivamente:

- adicionar novos métodos; - estender a estrutura de dados; - redefinir a implementação de métodos já existentes. Uma Classe “base” propicia a funcionalidade que é comum a todas as suas classes derivadas, enquanto que

uma

classe

funcionalidade

derivada

adicional

que

proporciona especializa

a seu

comportamento. A Generalização é uma noção conceitual. Herança é a implementação de uma generalização.

4.6 - Herança Herança é o compartilhamento de atributos e operações entre

classes

com

base

em

um

relacionamento

hierárquico. Cada subclasse herda todas as propriedades da superclasse e acrescenta suas próprias e exclusivas características,

permitindo

especificações comuns.

18

assim,

a

reutilização

de


4.7 – Composição por agregação Propriedade de uma Classe formar suas instâncias a partir da reunião das características e do comportamento de outras instâncias da mesma Classe ou de Classes diferentes, sendo que os componentes têm existência independente em relação ao composto, ou seja, a eliminação do composto não afeta a existência dos elementos que o criaram. É uma associação entre um objeto e outros objetos que fizerem parte dele.

PEDIDO

PRODUTO

CLIENTE

Se A agrega B então B é parte de A; mas seus tempos de vida são independentes.

4.8 – Composição Propriedade de uma Classe formar suas instâncias a partir da reunião das características e do comportamento de outras instâncias da mesma Classe ou de Classes diferentes, sendo que os componentes não têm existência indepedente em relação ao composto, ou seja, a eliminação do composto afeta a existência dos elementos que o criaram.

19


LÂMPADA

BULBO

BASE

FILAMENTO

Se A é composto de B então A controla o tempo de vida de B.

4.9 – Classes abstratas São Classes utilizadas apenas para organizar a estrutura, já que ela não será instanciada. Ela define um conjunto mínimo de atributos e métodos virtuais, que deverão ser implementados pelas SubClasses. Uma Classe abstrata sugere uma técnica de “design” e muitas vezes aumenta a clareza da modelagem. CLASSE ABSTRATA

ALUNO

CLASSES CONCRETAS

GRADUAÇÃO

PÓS

Uma Classe Abstrata é uma classe que: Provê organização; Não possui instâncias; Possui uma ou mais operações abstratas; Possui subclasses que implementam estas operações. Uma operação abstrata só determina a existência de um

comportamento

implementação.

20

não

definindo

uma


4.10 – Relacionamentos Um relacionamento modela uma conexão física ou conceitual entre objetos. Os relacionamentos são sempre bidirecionais e permitem uma visualização do número de objetos que podem ser associados. Todo relacionamento deve possuir um verbo que o identifica.

CLIENTE

1

*

FAZ

PEDIDO

Relacionamentos possíveis: GERENTE

EMPREGADO

DEPTO.

CLIENTE

ALUNO

1

PARTICIPA

1

1

PARTICIPA

0...1

1

ALOCA

1...*

1

FAZ

1

EMPRESTA

*

0...5

PROJETO

EXATAMENTE 1

PROJETO

OPCIONAL 0 OU 1

EMPREGADO

OPCIONAL 1 OU MUITOS

PEDIDO

MAIOR OU IGUAL A ZERO

LIVRO

NUMÉRICAMENTE ESPECIFICADO

4.11 – Polimorfismo Pode-se declarar funções e procedimentos com os mesmos nomes, enquanto suas chamadas possam a ser distintas pelos seus parâmetros de retorno, consistindo do número dos seus argumentos e dos seus tipos de valores de retorno. No contexto OO, Polimorfismo significa que diferentes tipos de Objetos podem responder a uma mesma mensagem de maneiras diferentes. 21


Aplicação financeira

CalcularSaldo(...)

Renda fixa

Poupança

CalcularSaldo(...)

CalcularSaldo(...)

Pode-se declarar funções e procedimentos com os mesmos nomes, enquanto suas chamadas possam a ser distintas pelos seus parâmetros de retorno, consistindo do número dos seus argumentos e dos seus tipos de valores de retorno.

22


5 – Métodos para análise com orientação a objetos A Análise Orientada a Objeto remonta a década de 80, com modelos que estendiam o Modelo Entidade Relacionamento. Do crescimento dos métodos de BOOCH e OMT, independentemente, e o reconhecimento pela classe usuária mundial, nasceu uma tentativa de padronização dos métodos de AOO, por Grady Booch e James Rumbaugh criação da Rational Corporation (1994). Ivar Jacobson juntou-se a equipe em 1995, integrando seu método OOSE. Receberam, então, a incumbência de c riar uma linguagem de modelagem unificada que tratasse assuntos de escala inerentes a sistemas complexos e de missão crítica, que se tornasse poderosa o suficiente para modelar qualquer tipo de aplicação, de tempo real, cliente servidor, ou outros tipos de software padrão.

5.1 – O método BOOCH O método de BOOCH consistia no emprego de técnicas de desenho orientado a objeto, apesar de ter sido estendido para contemplar também a AOO. Descreve um objeto como sendo um modelo do mundo real que consiste de dados e habilidades para o tratamento desses dados. Argumenta que o desenho estruturado funciona bem com linguagem de programação estruturada, e que o enfoque estruturado direciona a concentração dos esforços na lógica do módulo, dando pouca ênfase no uso dos dados. O desenho orientado a objeto é organizado via abstrações algoritmicas de forma parecida à programação orientada a objeto. Estreita relação entre desenho e programação permite tomar decisões de negócio antes da criação do código.

23


5.2

–

O

método

OMT

(Object

Modeling

Techinique) Desenvolvido pela GE Corporation, conhecido como Técnica

de

Modelagem

de

Objetos.

Baseado

na

modelagem semântica dos dados, derivado dos modelos estruturados. Suporta conceitos como: Atributos e Relacionamentos; Composição, Agregação e Herança. O seu ponto forte é a notação utilizada e o enfoque relativamente conservador. Um problema, em sua estrutura, é a falta de notação para representar a passagem de mensagens entre objetos.

5.3 – O método OOSE (Object-Oriented Software Engeneering) Foco em Casos de Uso e a categorização de pessoas e equipamentos. Técnica baseada em modelos de requerimento e análise que consistem em: Conjunto de Casos de Uso; Modelo de domínio do problema e Interface do sistema. O seu ponto forte é o método Objectory, que tem sido adaptado para a engenharia de negócio. Notação simplista usada para objetos de domínio.

24


6 – UML – Unified Modeling Language A UML não é uma metodologia, é uma linguagem de modelagem bem definida, expressiva, poderosa e aberta. Aprovada pela OMG Object Management Group em 1997 A UML pode ser usada para: Mostrar as fronteiras de um sistema e suas principais funções (Atores e Casos de Uso); - Ilustrar a realização de Casos de Uso com Diagramas de Interação; - Representar a estrutura estática de um sistema utilizando Diagramas de Classe; - Modelar o comportamento de objetos com Diagramas de Transição de Estado; - Revelar a arquitetura de implementação física com Diagramas de Componente e de Implantação; - Estender sua funcionalidade através de estereótipos.

7 – Visões em UML As visões são usadas em UML para descrever os diferentes aspectos do sistema sendo modelado. Uma visão é uma abstração do sistema, formada por um conjunto de diagramas.

A partir de um

conjunto de visões se chega a uma descrição completa do sistema a ser construído. Tipos de visões em UML:

Visão de Casos de Uso - mostra a funcionalidade do sistema do ponto de vista externo. Casos de uso podem ser descritos textualmente através de uma descrição do Fluxo de Eventos e/ou visualmente através dos Diagramas de Casos de Uso.

25


Visão Lógica - A visão lógica tem por objetivo descrever como a funcionalidade do sistema será obtida. A visão de casos de uso descreve o sistema do ponto de vista do mundo externo ao sistema. A visão lógica descreve o sistema do ponto de vista interno. descreve a organização do sistema, seus módulos principais,

como

eles

se

relacionam

e

suas

funcionalidades. A visão lógica envolve a estrutura estática do sistema (módulos, classes, objetos e relacionamentos) e também os aspectos dinâmicos (manifestados através de mensagens entre objetos, eventos externos, etc). A estrutura estática é descrita através de diagramas de classes. O modelamento dinâmico é feito através de diagramas de sequência, diagramas de colaboração e diagramas de estado.

Visão de Componentes - descreve a arquitetura física do sistema, em termos de componentes de software

26


8 – Diagramas da UML Para que as visões possam ser visualizadas graficamente, a UML dispõe de vários tipos de diagramas :

1. Diagramas de casos de uso (casos + atores + relações) 2. Diagramas de seqüência (detalhamento - fase projeto) 3. Diagramas de colaboração (troca de mensagens entre objetos)

4. Diagramas de classes (classes + responsabilidades -atributos, relacionamentos, métodos, cenários)

5. Diagrama de atividades (ordenamento dos casos de uso) 6. Diagramas de estados (ciclos de vida, comportamentos) 7. Diagrama de componentes (grupo de objetos divididos em nodos físicos) ·Visão de Implantação – mostra a alocação dos componentes de

software no equipamento alvo.

27


8.1 – Diagrama de casos de uso A modelagem de um diagrama de casos de uso é uma técnica usada para descrever e definir os requisitos funcionais de um sistema. Eles são escritos em termos de atores externos, casos de uso e o sistema modelado. Os atores representam o papel de uma entidade externa ao sistema como um usuário, um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicação com o sistema através dos casos de uso, onde o caso de uso representa uma sequência de ações executadas pelo sistema e recebe do ator, que lhe utiliza, dados tangíveis de um tipo ou formato já conhecido, e o valor de resposta da execução de um caso de uso (conteúdo) também já é de um tipo conhecido, tudo isso é definido juntamente com o caso de uso através de texto de documentação. O objetivo final do sistema é oferecer a funcionalidade descrita pelos casos de uso. Sendo assim, a visão dos casos de uso é importante também na validação do sistema. Exemplo: SISTEMA DE VENDAS

Dados do cliente para pesquisa

Dados do atendimento

EFETUAR VENDA Dados da autorização Adm. Cartões

Operador de caixa

28


8.1.1 – Simbologia para diagramas de casos de uso

Caso de uso ATOR

COMUNICAÇÃO Rótulo

Interação bidirecional

Rótulo

Interação Unirecional RELAÇÕES

<< USES >>

Uses - Passos comuns

<< EXTENDS >>

Extends - Passos adicionais Extends - Passos adicionais Generalização / Especialização

8.1.2 – Interações em casos de uso

Comunicação : um Ator comunica-se com o Caso de Uso. Extensão: demonstra como o comportamento definido para o primeiro caso pode ser inserido no comportamento definido para o segundo. Sugere a existência de casos adicionais e alternativos.

Generalização: um caso de uso é uma especialização de outro, e herda características.

Uso ou inclusão: ocorre quando surge a divisão de um caso de uso mais complexo, que inclui outros mais simples, e a identificação de passos comuns, que podem ser reutilizados por outros casos de uso. O tipo de generalização <> é usado para descrever o comportamento comum entre dois ou mais

Casos de uso.

29


O tipo de generalização <> é usado para expressar comportamento opcional por um Caso de

uso.

30


8.2 – Diagrama de classes No modelamento orientado a objetos, classes, objetos e seus relacionamentos constitnuem os principais elementos de modelamento. Uma classe é a descrição de um conjunto de

objetos

semelhantes – os objetos constituem instâncias de uma classe. Uma classe descreve as propriedades e o comportamento dos objetos que ela define. O diagrama de classes demonstra a estrutura estática das classes de um sistema onde estas representam as "coisas" que são gerenciadas pela aplicação modelada. Classes podem se relacionar com outras através de diversas maneiras: -

Associação (conectadas entre si).

-

Composição (Uma classe é criada a partir de outras

classes

existindo

uma

relação

de

dependência entre elas). -

Composição por agregação ( Uma classe é criada a

partir de

outras

classes

não

existindo,

entretanto, uma relação de dependência entre elas). -

Especialização / Generalização (Uma classe é uma especialização de outra classe).

8.2.1 – Simbologia

31

Ciência da computação – Análise e projeto de sistemas com orientação a objetos 5º Semestre - Professor: José Luiz Rodrigues Junior CLASSE NOME ATRIBUTOS MÉTODOS

Verbo

ASSOCIAÇÃO GENERALIZAÇÃO / ESPECIALIZAÇÃO

COMPOSIÇÃO POR AGREGAÇÃO

COMPOSIÇÃO

8.2.2 – Classes e domínio do problema Ao se modelar um sistema através de objetos é natural que apareçam classes que descrevem conceitos e situações no domínio do problema. Por exemplo, ao se modelar um sistema de administração escolar, são usadas classes como estudante, curso, currículo, professor e matrícula, entre outras. Baseando-se em objetos e partindo de classes no domínio do problema é possível se construir sistemas que conseguem evoluir junto com os requisitos: mesmo que os requisitos evoluam e que seja necessário adicionar novas funcionalidades, o domínio do problema (em geral) continua sendo o mesmo.

8.2.3 – Relacionamento entre classes Num sistema, as classes podem ter diversos tipos de relacionamentos entre si. Uma associação é o tipo mais comum desses relacionamentos. Uma associação é uma “conexão” bidirecional entre duas classes. Classes

Elementos de um relacionamento:

Relacionamento

Prédio 1

possui

32

Cardinalidade

Apartamento

*


33


8.2.3.1 – Cardinalidade / Multiplicidade A cardinalidade permite restringir o número de elementos que podem se relacionar. Cardinalidades possíveis:

N 0...1 N...M

*

1...

*

Exatamente N 0 ou 1 Entre N e M (Incluindo os extremos) Zero ou Muitos 1 ou muitos

Exemplo: supondo que país e cidade são classes num sistema, um país está associado a uma cidade que é a sua capital.

CIDADE

PAÍS Tem capital É capital de

No relacionamento entre duas classes, cada uma desempenha um papel específico. Esse papel, sempre que possível, deve ser explicitado no modelo. No exemplo anterior, No exemplo anterior, Tem capital corresponde ao papel da classe Pais e É capital de corresponde ao papel da Cidade no mesmo relacionamento.

34

Ciência da computação – Análise e projeto de sistemas com orientação a objetos 5º Semestre - Professor: José Luiz Rodrigues Junior DISCIPLINA

ALUNO

1

Está matriculado em

1...*

Exemplo: num sistema de administração escolar, um aluno pode se inscrever em zero ou várias disciplinas.

8.3 – Diagrama de sequência Um diagrama de seqüência mostra os objetos participando de uma interação arranjada em uma seqüência de tempo. Uma interação é o comportametno que compreende um conjunto de mensagens trocadas entre um conjunto de objetos em determinado contexto para a realização de um propósito. Interação = troca de mensagens entre objetos p/ realizar alguma atividade. O mais importante aspecto deste diagrama é que a partir dele percebe-se a sequência de mensagens enviadas entre os objetos. Uma mensagem é a especificação de uma comunicação entre objetos, a qual contém informações relacionadas ao que se espera resultar dessa atividade.

8.3.1 - Simbologia

35

Ciência da computação – Análise e projeto de sistemas com orientação a objetos 5º Semestre - Professor: José Luiz Rodrigues Junior UM OBJETO: XXXXXXXX

OBJETO

COMUNICAÇÃO

ESTEREÓTIPO

LINHA DE VIDA

Um diagrama de seqüência tem duas dimensões: A vertical que representa o tempo, e A horizontal, que representa os diferentes objetos. Um objeto é mostrado com uma linha pontilhada vertical chamada de "linha da vida". A linha da vida representa a existência do objeto em um tempo determinado. As mensagens podem ser divididas em:

Simples= não descreve detalhes da mensagem por não ser importante neste momento ou por não se saber os pormenores da comunicação.

Síncrona = mensagem para chamada de operação, a próxima mensagem só é executada quando esta for concluída.

Assíncrona=serve para envio de mensagem sem nenhuma espera, ou seja, a próxima mensagem pode ser executada antes que esta termine. Notação:

SÍNCRONA

SIMPLES

36

ASSÍNCRONA


Se o objeto é criado ou destruído durante o período de tempo mostrado no diagrama, então a linha da vida começa e pára no ponto apropriado; caso contrário ela vai desde o início até o fim do diagrama. Se o objeto é criado durante o diagrama, então a mensagem que o cria é desenhada com a ponta da seta para o símbolo de objeto. Se o objeto é destruído durante o diagrama, então sua destruição é marcada por um "X", ou na mensagem que causa a destruição ou na mensagem final retornada pelo objeto destruído.

37


Exemplo de diagrama de seqüência: c:Cliente

:Agente Viagem

p: Assistente de Planejamento

<> definir_Itinerário(i) estabelecer_rota( ) rota

notificar( )

Os diagramas de seqüência podem ser usados de forma genérica e como uma instância. A forma genérica descreve todas as possíveis alternativas em um cenário. Um cenário é uma descrição de um evento específico. Existem duas possibilidades de cenário: Cenário primário: Que descreve as ações do evento sem qualquer alusão a problemas que podem ocorrer durante o processamento. Cenário secundário: Que descreve uma situação que não se aplica às regras do cenário primário.

Ex.: Um cenário de abertura de uma conta bancária deveria descrever: uma abertura de conta bem sucedida, uma abertura de conta não concedida por falta de crédito do cliente e uma abertura de conta com um depósito imediato na conta. Um diagrama de seqüência instanciado deveria mostrar somente uma destas possibilidades.

38


8.4 – Diagrama de colaboração O diagrama de colaboração não mostra o tempo como uma dimensão separada, então a seqüência de mensagens deve ser determinada usando-se números em seqüência. Os diagramas de colaboração mostram os relacionamentos entre os objetos. Pode-se escolher entre utilizar o diagrama de colaboração ou o diagrama de seqüência. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de seqüência. Se a ênfase for o contexto do sistema, é melhor dar prioridade ao diagrama de colaboração. Exemplo:

8.5 – Diagrama de Atividades São usados em situações onde todos ou a maioria dos eventos

representam

internamente

(isto

é,

a

conclusão

fluxo

de

das

controle

ações

geradas

procedimental).

Normalmente descreve etapas seqüenciais (e possivelmente concorrentes) em um processo computacional. Geralmente utiliza-se esse tipo de diagrama para modelar fluxo de trabalho e operações, no entanto é possível utilizá-lo também para modelar o fluxo do sistema como um todo.

39


8.5.1 - Simbologia INÍCIO DO DIAGRAMA

FIM DO DIAGRAMA

ATIVIDADE

DECISÃO

CONECTOR (MESMA PÁGINA)

Exemplo de diagrama de atividade:

Selecionar local

Contratar arquiteto

Desenvolver plano

Orçar plano

Rejeitado

Aceito

Executar trabalho em outros setores

Executar trabalho no local

Construir edifício

40


O exemplo de diagrama acima, mostra uma bifurcação . Quando são modelados fluxos de trabalho em processos de negócios, geralmente ocorrem fluxos concorrentes. Nesses casos utiliza-se uma barra para a bifurcação e a união dos fluxos paralelos de controle.

8.5.2 - Raias Esse recurso é útil na modelagem de fluxo de trabalho pois possibilita particionar em grupos os estados. Cada grupo é chamado de raia sem semântica profunda, exceto por representar alguma entidade do mundo real. Num diagrama com raias, cada atividade pertence exclusivamente a uma raia, mas as transições poderão cruzar as raias. Exemplo:

41


8.6 – Diagrama de estados Um diagrama de estado representa o ciclo de vida de um objeto. Para isso ele mostra os estados que um objeto pode ter e como os eventos afetam estes estados. Podem ser considerados eventos o recebimento de uma mensagem, uma condição que se tornou verdadeira ou a passagem de um período de tempo designado após um determinado evento. O objeto emite uma resposta a um estímulo(evento) recebido. Um estado é uma condição durante a vida de um objeto ou uma interação durante a qual ele: - Satisfaz alguma condição, - Executa alguma ação, - Espera algum evento.

8.6.1 - Simbologia INÍCIO DO DIAGRAMA

FIM DO DIAGRAMA

ESTADO

DECISÃO

CONECTOR (MESMA PÁGINA) CONECTOR (PÁGINA ANTERIOR/PRÓXIMA)

8.6.2 - Evento Um evento é uma ocorrência que pode disparar uma transição do estado. Cada nome de evento pode aparecer no máximo uma vez em um único estado.

42


43


8.6.3 – Transição Uma transição é representada por uma seta sólida de um estado para outro, rotulada por uma cadeia de transição. Exemplo de diagrama de estados: cancelamento de pedido solicitado Cancelando Pedido pedido enviado

alteração de pedido solicitada Alterando Pedido

Registrando Pedido

pedido cancelado pedido requisitado para análise

pedido requisitado para análise

pedido será cancelado Analisando Pedido pedido para aprovação pedido já pode ser atendido

Aprovando Pedido pedido não pode ser atendido no momento

pedido será atendido Atendendo pedido

Colocando pedido em pendência

pedido atendido

8.7 – Diagrama de componentes Componentes modelam coisas físicas que podem residir em um nó, como: executáveis, bibliotecas, tabelas, arquivos e documentos. Um nó é um objeto físico que representa um recurso computacional. Nós geralmente incluem computadores com processadores, e dispositivos, como impressoras, leitoras de cartão, dispositivos de comunicação, etc. Assim como na análise, para a implementação de um software é necessário estabelecer qual a modelagem física do sistema executável.

44


Um diagrama de componentes mostra as dependências entre componentes de software, incluindo componentes de código fonte, componentes de código binário e componentes executáveis. É um grafo de componentes conectado por relacionamentos de dependência.

45


Exemplos: Modelagem de uma aplicação:

Modelagem de um banco de dados físico:

<>

escola.db

<>

<

>

curso

aluno

<

>

departamento

<

>

<

>

professor

escola

46


8.8

–

Diagrama

de

implantação

(Ou

disponibilidade) Os diagramas de implantação são utilizados para a modelagem da visão estática de funcionamento de um sistema. Essa visão é direcionada para a distribuição, entrega e instalação das partes que formam o sistema físico. São utilizados para visualizar, especificar e documentar sistemas embutidos, cliente/servidor e distribuídos. Envolvem a topologia do sistema, descrevendo a estrutura de hardware. Esses

diagramas

mostram

a

configuração

de

nós

de

processamento em tempo de execução e os componentes que neles existem. Componentes que não existem em tempo de execução não aparecem nestes diagramas. São diagramas úteis também para a engenharia reversa. Exemplos de diagrama de componentes:

<>

terminal <>

<>

servidor <>

terminal <>

Os servidores nacionais podem ser alcançados um pelo outro por meio da rede privada da empresa.

<> <>

terminal

terminal

<>

terminal

<>

servidor nacional

internet <>

servidor regional

47 <>

servidor regional

servidor de login <>

servidor regional

Report "An_liseeprojetodesistemasorientadosaobjetos-notasdeaula"

Your name

Email

Reason

Description

Copyright © 2025 IDOC.TIPS. All rights reserved.
About Us | Privacy Policy | Terms of Service | Copyright | Contact Us | Cookie Policy

Sign In

Email

Password

Remember me Forgot password?

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close

An_liseeprojetodesistemasorientadosaobjetos-notasdeaula

Recommend Documents