projeto fÍsico de sistemas de informaÇÃo · projeto físico de sistemas de informação –...

Projeto Físico de Sistemas de Informação – Prof. Antonio Geraldo da Rocha Vidal 1

PROJETO FÍSICO DE

SISTEMAS DE INFORMAÇÃO

FEA/USP EAD-5881 – Tecnologia de Informática

Prof. ANTONIO GERALDO DA ROCHA VIDAL

[email protected]

Agosto/2003


SUMÁRIO

Introdução....................................................................................................................................... 5

Modelo Funcional ........................................................................................................................... 6

Objetivos ..................................................................................................................................... 6

Diretrizes Gerais do Sistema ........................................................................................................ 6

Modelo Conceitual....................................................................................................................... 6

Definição e Objetivo................................................................................................................. 6

Elementos Constituintes e Notações.......................................................................................... 6

Diagrama de Use Cases (Casos de Uso) ....................................................................................... 7

Definição e Objetivo................................................................................................................. 7

Elementos Constituintes e Notações.......................................................................................... 7

Construção do Diagrama Use Case ........................................................................................... 9

Recomendações........................................................................................................................ 9

Benefícios .............................................................................................................................. 10

Modelo Estático ............................................................................................................................ 10

Diagrama de Classes.................................................................................................................. 10

Definição e Objetivo............................................................................................................... 10

Elementos Constituintes e Notações........................................................................................ 10

Construção do Diagrama de Classes ....................................................................................... 13

Recomendações...................................................................................................................... 13

Benefícios .............................................................................................................................. 14

Transformação do Diagrama de Classes em Modelo de Dados................................................ 14

Recomendações para a transformação do Diagrama de Classes em Modelo de Dados............. 14

Modelo Dinâmico ......................................................................................................................... 15

Diagrama de Estados ................................................................................................................. 15



Construção do Diagrama de Estado ........................................................................................ 16

Recomendações...................................................................................................................... 17

Benefícios .............................................................................................................................. 17

Diagrama de Seqüência.............................................................................................................. 18




Construção do Diagrama de Seqüência ................................................................................... 18

Recomendações...................................................................................................................... 19

Benefícios .............................................................................................................................. 19

Diagrama de Colaboração .......................................................................................................... 20



Construção do Diagrama de Colaboração ............................................................................... 21

Recomendações...................................................................................................................... 21

Benefícios .............................................................................................................................. 21

Modelo de Implementação ............................................................................................................ 22

Diagrama de Pacotes.................................................................................................................. 22


Recomendações...................................................................................................................... 22

Benefícios .............................................................................................................................. 22

Diagrama de Componentes ........................................................................................................ 23



Recomendações...................................................................................................................... 24

Benefícios .............................................................................................................................. 24

Diagrama de Distribuição .......................................................................................................... 24



Recomendações...................................................................................................................... 25

Recomendações...................................................................................................................... 26

Benefícios .............................................................................................................................. 26

Protótipo de Entradas e Saídas (Interface) ..................................................................................... 26


Elementos Constituintes e Notações: ...................................................................................... 26

Recomendações...................................................................................................................... 26

Projeto de Banco de Dados ........................................................................................................... 28

Modelo de Banco de Dados (MDB) ........................................................................................... 28

Definição e Objetivo:.............................................................................................................. 28



Perfil Operacional ......................................................................................................................... 29



Modelo de Entradas e Saídas Estendido ........................................................................................ 30

Protótipo Estendido.................................................................................................................... 30



Especificação de Componentes .................................................................................................. 31


Recomendações...................................................................................................................... 31

Plano de Testes ............................................................................................................................. 32



Configuração de Ambientes .......................................................................................................... 34

Definição e Objetivo .................................................................................................................. 34


Modelos de Diagramas da UML.................................................................................................... 35

Diagrama de Use Cases.............................................................................................................. 35

Diagrama de Classes.................................................................................................................. 36

Diagrama de Estados ................................................................................................................. 37

Diagrama de Seqüência.............................................................................................................. 38

Diagrama de Colaboração .......................................................................................................... 39

Diagrama de Pacotes.................................................................................................................. 40

Diagrama de Componentes ........................................................................................................ 41

Diagrama de Distribuição .......................................................................................................... 42

Glossário....................................................................................................................................... 43

Bibliografia................................................................................................................................... 44


Introdução Esta apostila tem por finalidade introduzir as técnicas utilizadas para o projeto físico de sistemas de informação baseados em tecnologia Orientada a Objetos e na UML – Unified Modeling Language. Como cada componente do sistema pode ser representado através de técnicas e produtos (diagramas, etc.) distintos, torna-se necessário uma descrição sucinta de cada uma dessas técnicas e produtos, em termos de sua definição e objetivo, de seus elementos constituintes, das notações possíveis e dos padrões e diretrizes de qualidade técnica a serem adotados pelos desenvolvedores.

A figura a seguir apresenta uma visão geral das várias técnicas e diagramas de projeto que compõe a UML, categorizando-os em modelos que acordo com cada aspecto do sistema que visam representar.

Relacionamentos entre os vár ios diagramas UML

D iag rama U se Case

1 ..*

1

D iag rama C la sses D iag rama E stad os

D iag rama Se qu en cia

o b je to 3o b je to 2 :c la s s e 1o b je to 1 :c la s s e 1

objet o3: Def init ion

objet o2: classe1

objet o1: classe1

2: <anonym ous>

3: <an ony m ou s>

4: <anonym ous>

1: <anonym ous>

D iag rama C ol ab oraçã o

Co m m e n tCo m m e n t

D iag rama C omp o nen te s

D iag rama Pa cot es

É C O NSO -

LID AD O

É REQ U I-SITO

G ERA / V ALID A

SÃ O RETIFICA DO S

S E R V ID O R D E A P L IC A C A O

WW W .C L IE N T E

S E R V ID O R D E D A D O S

E M P R E S T IM O .H T M LC o m m e n t

C O N S U L T A .H T M LC o m m e n t

G E R E N T E .H T M LC o m m e n t

C A D A S T R O .H T M L

C o m m e n t

U S U A R IO .C L A S S

C o m m e n t

M A T E R IA IS .C L A S S

C o m m e n t

L IV R O S .C L A S SC o m m e n t

R E V IS T A S .C L A S SC o m m e n t

S C R IP T .S Q L

C o m m e n t

D A O -D a ta A c c e s s O b je c ts

C o m m e n t

D iag rama d eD ist ri bu iç ão

M O D ELOF U NC IO N A L

M O D ELOES TÁ TIC O

M O D ELOD IN ÂM IC O

M O D ELO D EIM P LEM EN TA Ç ÃO


Modelo Funcional É responsável pela representação da funcionalidade do sistema, em termos de o que um sistema deve realizar.

Objetivos Declaração dos objetivos que devem ser atingidos com a implantação do Sistema.

Diretrizes Gerais do Sistema • Características Técnicas: a plataforma tecnológica em que o Sistema deverá ser desenvolvido;

• Requisitos: especificação dos requisitos dos usuários;

• Restrições: fatores que norteiam e restringem o desenvolvimento do Sistema;

• Prioridades: lista das prioridades definidas para o desenvolvimento do Sistema;

• Benefícios: lista dos benefícios esperados pelos usuários com a implantação do Sistema.

Modelo Conceitual

Definição e Objetivo

Delimita a área de abrangência do Sistema a ser desenvolvido (domínio do problema). Este produto não é contemplado na UML, mas obtido a partir do Projeto Conceitual do Sistema.

Elementos Constituintes e Notações

• Modelo de Processos: único e representando todo o Sistema.

• Funções do Sistema: funções que implementam as regras de negócio e outros recursos que serão automatizadas pelo sistema.

• Entidades Externas: elementos externos com os quais o Sistema se comunica e respectivos fluxos de dados.

• Modelo de Dados: único e representando todo o Sistema.

• Entidades: tabelas (arquivos de dados) que comporão o banco de dados no qual se baseará o sistema;

• Relacionamentos: relações entre as tabelas que definirão as regras de integridade e os relacionamentos entre os objetos do banco de dados.

• Módulos do Sistema: único e representando todo o Sistema.

• Diagrama Hierárquico do Sistema: representando os módulos que compõem o sistema e sua relação de contexto e hierarquia para a implementação das operações do Sistema.

• Interface com o Usuário: definição e protótipo dos elementos de comunicação com o usuário (telas, formulários, relatórios e diálogos).


Diagrama de Use Cases (Casos de Uso)


Os diagramas de Use Cases (Casos de Uso) são produtos de modelagem funcional que têm como objetivo representar um sistema como um conjunto de interações com os vários atores (os usuários) envolvidos desde o momento em que uma ação é solicitada até o término dos últimos efeitos derivados da execução das operações do Sistema.


São seis os elementos básicos de um Diagrama Use Cases:

• Ator: agente externo, entidade que interage (envia e/ou recebe mensagens) com um Sistema. Um ator deve ser considerado uma classe de objetos e não uma instância (indivíduo/objeto) dessa classe. Por exemplo, um ator de um Use Case de consulta da folha de pagamento pode ser o Diretor, e não o João. Um ator é sempre representado por um ser humano estilizado:

• Use Case: grupo de seqüências de ações que o Sistema executa, a partir do estímulo fornecido por um ator, e cujo resultado final é destinado também a um (ou mais) ator(es). As ações executadas dentro de um Use Case podem envolver comunicação com vários outros atores, cálculos e funções realizadas pelo Sistema.

• Associação de Comunicação: ligação simples que mostra a comunicação entre um ator e um Use Case, representada sempre por uma linha reta (um-para-um, sem direção) entre eles:

DIRETOR

CONSULTAR

FOLHA DE PAGTO

DIRETOR

CONSULTAR FOLHA DE PAGTO


• Relacionamento Extends: deve ser usado quando um Use Case é similar a outro, mas faz um pouco mais que este. Geralmente, um Use Case estendido pode tratar exceções como casos específicos do Use Case geral.

Por exemplo: dado um Use Case básico “Informar a quantidade de produtos pedidos”, pode haver alguns limites para este Use Case como, por exemplo, limitar a quantidade de produtos pedidos por cliente. Neste caso, além dos procedimentos normais descritos no Use Case básico, também é utilizado o Use Case estendido “Verificar limite de produto”.

Uma maneira de identificar variações é colocar os procedimentos normais em um Use Case básico e os procedimentos de tratamento de exceções em outros Use Case estendidos.

1. Primeiro descrever o Use Case normal, básico, sem exceções;

2. Para cada passo do Use Case básico perguntar: “O que poderia acontecer de errado?” e “Como seria o procedimento para tratar o erro?”;

3. Colocar todas as variações do Use Case básico como extends em Use Case estendidos.

Um relacionamento Extends é representado por uma generalização, através de uma flecha apontando para o Use Case a ser estendido, com o estereótipo <<extends>> .

• Relacionamento Uses: quando vários Use Cases possuem um comportamento em comum, este pode ser modelado em um Use Case específico, que deve ser usado integralmente pelos demais. Um relacionamento Uses é representado por uma generalização, através de uma flecha apontando para o Use Case a ser usado, com o estereótipo <<uses>> .

• Notas:

1. Comentário elucidativo acerca de um Use Case, ator, relacionamento ou associação, dentro de um diagrama.

DIRETOR

Diretor deTecnologia

CADASTRA

USUARIO

EMPRESTA

MATERIAL

<<uses>>

INFORMARQTDE PRODUTOS

PEDIDOS

<<extends>> VERIFICARLIMITE DE

PRODUTOS


2. Existem similaridades e diferenças entre os relacionamentos extends e uses. Ambos implicam em procedimentos comuns de vários Use Cases que são usados ou estendidos para vários outros Use Cases;

3. No relacionamento extends os atores tem um relacionamento para o Use Case que está sendo estendido. É assumido que o as atores executarão ambos Use Cases, o básico e o estendido. Com o relacionamento uses não há atuação do ator associado ao use case básico;

4. Aplicar as seguintes regras:

4.1. Utilizar extends quando estiver descrevendo uma variação do procedimento normal ou padrão;

4.2. Utilizar uses quando estiver repetindo parte do procedimento em mais de um Use Case para evitar esta repetição.

Construção do Diagrama Use Case

1. Criar uma lista com os possíveis Atores do Sistema

2. Filtrar a lista e definir os Atores do Sistema

3. Para cada Ator, criar uma lista com os possíveis casos de uso (Use Case)

Ex.: Ator = Cliente � cadastra pessoa

� consulta pessoa

� encerra cadastro

4. Filtrar a lista e definir os Use Cases para cada Ator

5. Representar cada Ator com seus Use Cases no Diagrama

6. Tentar estabelecer uma ordem dos Use Cases, para facilitar o entendimento do problema

7. Consultar o Projeto Conceitual e realizar levantamentos adicionais e para definir as Regras de Negócio envolvidas no Use Case

8. Documentar, para cada Use Case, as regras de negócio levantadas (classe, atributos e relacionamentos) do Sistema.

Recomendações

• Cada Ator deve possuir uma única missão, embora possa utilizar diversos Use Cases.

• Cada Ator deve possuir uma única missão, mas podem ser agrupados em um conjunto de atores, generalizando sua missão.

• Cada Use Case deve possuir uma única missão (evitar usar “e” para definir um Use Case).

• Cada Use Case deve possuir uma única missão, mas pode ser agrupado um conjunto de Use Cases afins em um Use Case com missão generalista.

• Deve ser usada a notação padrão preconizada pela UML (Unified Modeling Language), já demonstrada acima.

• As seguintes nomenclaturas devem ser seguidas nos projetos a serem desenvolvidos dentro do padrão da UML:


o Atores: utilizar um nome no singular, que represente o objeto, unidade organizacional ou Sistema em questão. Utilizar letras maiúsculas.

Ex.:

→ CLIENTE

o Use-Cases: utilizar um verbo ativo no infinitivo, ou um substantivo derivado de um verbo, que represente a principal atividade realizada, seguido de um objeto, com caracteres maiúsculos.

Ex.:

→ CONSULTA GENÉRICA

→ CONSULTAR POR RH/PRODUTO

o Associações de Comunicação: não possuem nome.

o Relacionamento Extends: deve ser utilizado o estereótipo <<extends>> .

o Relacionamento Uses: deve ser utilizado o estereótipo <<uses>> .

o Notas: não se aplica nenhum padrão de nomenclatura.

Benefícios

• O Diagrama de Use Cases é uma técnica que complementa o Projeto Conceitual e auxilia na análise das interfaces externas do Sistema e na definição de suas funcionalidades.

• O Diagrama de Use Cases prepara a modelagem das Classes, porque auxilia no levantamento de atributos e regras de relacionamento.

• O Diagrama de Use Cases será transformado no Protótipo de Entradas e Saídas do Sistema (formulários, páginas, relatórios e estrutura de navegação).

Modelo Estático É o modelo fundamental da UML, responsável pela representação das estruturas de informação que sustentam as funções e operações do Sistema.

Diagrama de Classes


O Diagrama de Classes é um produto de modelagem de estruturas de informação, que tem como objetivo fornecer uma visão estática do Sistema, em termos das classes (descrevendo suas propriedades (dados e conteúdo) e seu comportamento) e dos vários tipos de relacionamentos entre elas, em um alto nível de abstração.


São vários os elementos básicos de um Diagrama de Classes:


• Classe: representação de um tipo de objeto do mundo real, materializada no sistema através de uma estrutura composta de atributos (propriedades ou dados) e de comportamentos (operações e métodos), unicamente identificada por um nome.

• Atributos: compõem a classe e descrevem as propriedades de seus objetos que são importantes

para o escopo do sistema.

Cada atributo deve ter:

- Tipo: obrigatório; ex.: char, integer, float, date, etc.

- Condição de visibilidade: opcional

público – pode ser visto e usado fora da classe

privado – não pode ser visto de fora da classe

- Valor inicial: opcional

- Lista de valores discretos possíveis: opcional

• Operações: são utilizadas principalmente para manipular as propriedades (atributos ou dados) dos objetos de uma classe. Cada operação deve ter:

- Tipo do valor de retorno: obrigatório; ex.: char, integer, float, date, etc.

- Lista de parâmetros: obrigatório.

- Condição de visibilidade: opcional (como os atributos).

• Persistência: é a propriedade pela qual um Objeto pode ter suas instâncias registradas em um meio físico (por exemplo, ter o registro de suas instâncias em uma tabela de banco de dados).

OBS.: As Classes Persistentes são transformadas em Entidades no Modelo de Entidade Relacionamento, ou Tabelas no Modelo de Dados.

• Relacionamento de Associação: conjunto de conexões entre os objetos de duas (ou mais) Classes. Uma associação possui características como:

o Nome: identifica o relacionamento.

o Multiplicidade: número de instâncias de uma classe que podem estar relacionadas a uma

única instância das classes associadas

� 1-para-1: 1 - 1


� 1-para-muitos: 1 - *

� 1 (opcional)-para-muitos: 0..1 - *

� 1-para-1(opcional): 1 – 0..1

� 1-para-muitos (opcional): 1-0..*

� 1-para-um ou muitos: 1-1..*

Uma associação pode ser:

• Normal: caso mais comum de associação, representada por uma linha simples entre as classes associadas. No caso de associações muitos-para-muitos (N-para-N), deve ser utilizado um losango como ponto de conexão entre as classes.

��

�

• Agregação: caso especial de associação, onde existe uma relação de composição, ou seja,

um objeto de uma classe pode conter objetos de uma outra classe. Representada comumente por um losango junto à classe mais significativa na agregação.

• Relacionamento de Generalização ou Herança: conexão entre uma classe mais genérica

(superclasse) e uma mais específica (subclasse).

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Neste tipo de relacionamento, as subclasses herdam todos os atributos e as operações da superclasse, estendendo-a com novos atributos e operações específicas. Uma generalização é sempre representada como uma flecha saindo da subclasse e apontando para a superclasse.


• Relacionamento de Dependência: conexão entre um elemento independente e outro elemento dependente do primeiro. Uma mudança no elemento independente certamente afeta o elemento dependente. Podem ser considerados elementos quaisquer classes, pacotes, use-cases, etc.

Construção do Diagrama de Classes

1. Criar uma lista com as possíveis Classes do Sistema, tendo como base os levantamentos dos Use Cases (Diagrama de Use Cases) e dos Cartões CRC (Responsabilidade e Colaboração).

2. Filtrar a lista e definir as primeiras Classes do Sistema.

3. Definir as características de cada Classe (propriedades, métodos e relacionamentos).

4. Desenhar as Classes e suas características no Diagrama de Classes.

5. Desenhar os relacionamentos entre as Classes.

6. Completar os relacionamentos com sua cardinalidade e seu nome.

7. Refinar o Diagrama de Classes (diferenciar os tipos de associações e relacionamentos).

8. Definir as Operações comuns (Cria, Elimina, Recupera e Atualiza) de cada Classe.

9. Complementar as Classes com Operações do Negócio específicas de cada uma.

Recomendações

• Cada Classe deve possuir uma única missão.

• Todo relacionamento deve possuir cardinalidade.

• O nome dos relacionamentos é obrigatório.

• Apenas as Operações Públicas são identificadas em Análise (Cria, Elimina, Recupera, Atualiza e operações do negócio).

• As Operações Privadas somente serão definidas em Projeto para minimizar o trabalho, por exemplo, operações de persistência, validações, estados, etc.

• Os seguintes padrões de nomenclatura devem ser observados nos projetos a serem desenvolvidos:

o Classes: utilizar um substantivo, no singular, que seja relacionado ao domínio do negócio, e que não permita interpretações ambíguas. Utilizar até 30 caracteres descritivos e letras maiúsculas não acentuadas.

o Atributos: utilizar até 40 caracteres, onde a 1ª letra maiúscula e as demais letras minúsculas não acentuadas podem distinguir nomes simples e duplos.

o Operações: utilizar até 30 caracteres descritivos onde a 1ª letra maiúscula e as demais letras minúsculas não acentuadas.

OBS.: 1) A nomenclatura das classes não deve ter qualquer sufixo ou prefixo;


2) A dicionarização de cada atributo na classe deve conter:

<visibilidade> <nome>:<tipo> = <valor inicial> {<lista valores>}

Ex.: + Data_Inicial: data (atributo público da classe SERVICO)

- Valor_orçado: long = 0.00 (atributo privado da classe SERVICO)

3) A dicionarização de cada operação na classe deve conter:

<visibilidade> <nome>:<parametros>=<tipo retorno> {<lista valores>} onde:<parametros> deve ser: <nome>:<tipo> = <valor default}

Ex.: + Emitir Termo Abertura: (Num_serv:integer, Data:date=Now()):boolean

- Calcular Rentabilidade (Num_serv:integer): long

o Relacionamentos: utilizar verbos na voz ativa ou passiva, seguidos de uma preposição, caso seja necessário. Utilizar letras minúsculas.

Ex.: possui (SERVICO possui FOLHA DE TEMPO), trabalha em (COLABORADOR trabalha em SERVICO), etc.

o Relacionamentos de Generalização e Herança: não tem nomenclatura.

Benefícios

• Auxilia na análise do conhecimento do sistema (tudo o que o sistema deve conhecer e realizar).

• Será a base para a produção de código, sendo utilizado desde a Análise até a Construção.

• Será transformado no Projeto de Banco de Dados (relacional, OO, etc).

Transformação do Diagrama de Classes em Modelo de Dados

Como o Banco de Dados normalmente é Relacional e não Orientado a Objeto, não implementando diretamente o diagrama de classes, deve-se transformar o Diagrama de Classes em MER (Modelo de Dados ou Modelo de Entidade Relacionamento) para que possa ser implementado.

Em geral, o MER é utilizado para representar o Modelo Estático de sistemas desenvolvidos sob a ótica da Modelagem de Dados. Entretanto, mesmo quando são utilizadas técnicas de Projeto Orientado a Objetos, por exemplo, faz-se necessário o uso do MER para a representação das estruturas físicas, já que a realidade da maioria dos bancos de dados da atualidade está fortemente embasada no Modelo Relacional.

Recomendações para a transformação do Diagrama de Classes em Modelo de Dados

• Somente as classes persistentes do Diagrama de Classes terão uma entidade correspondente no MER;

• Como regra geral, cada atributo da classe corresponde a um atributo da entidade (tabela) no MER (Modelo de Dados);

• No MER deverão ser aplicadas as regras de normalização.


Modelo Dinâmico O modelo dinâmico é responsável pela representação do comportamento dinâmico do Sistema (quando em execução), em termos de como, quando e onde um Sistema deve executar suas operações.

Diagrama de Estados


O Diagrama de Estados é um documento que tem como objetivo representar, de forma esquemática, todos os estados que um objeto pode ter durante o seu ciclo de vida, o seu comportamento dentro desses estados, assim como os eventos que causam a mudança de um estado para outro.

A análise de Transição de Estado do Projeto Conceitual auxilia no estudo do comportamento de Classes que possuem instâncias com dinâmica complexa dentro do Sistema, pelo fato de que mesmo não modificando sua identidade, ou seja, a instância não deixa de existir, as Classes sofrem uma modificação na sua situação. Permite que para uma instância de uma Classe sejam definidas regras de negócio diferentes de acordo com o seu estado atual.


São 2 os elementos básicos de um Diagrama de Estados:

• Estado: situação na qual um objeto se encontra em um determinado momento, que pode ser resultante de atividades prévias por ele realizadas. Um estado, segundo a UML, é representado por um retângulo de cantos arredondados, com 2 compartimentos distintos:

o Variáveis de Estado: nesta divisão, são mostrados os atributos que têm importância para o estado em questão, e os valores a serem atribuídos a eles;

o Atividades: nesta divisão, são mostrados os eventos que influenciam o estado em questão, e as ações executadas como resposta a cada um destes eventos.

SERVIÇO EM ANDAMENTO

data abertura = data atual

do / ATUALIZAR FTentry / INICIALIZAR FTexit / SUSPENDER FT

Variáveis de Estado

Atividades


Um estado também pode ser:

o Inicial: Onde se inicia a dinâmica do diagrama, representado pelo símbolo

o Final: Onde termina a dinâmica do diagrama, representado pelo símbolo

o Indicador de Histórico: memória de um estado, ao qual pode-se retornar posteriormente, representado pelo símbolo H.

• Transição: representação esquemática da mudança de um estado para outro, representada através de uma flecha apontada para o estado destino. Uma transição pode ter associada a ela uma condição (que precisa ser verdadeira para que a transição ocorra) e um conjunto de ações, que devem ser executadas no contexto em questão.

Construção do Diagrama de Estado

1. Criar uma lista com os possíveis Estados de cada Classe do Sistema;

Ex.: Classe: Agência

aberta

criada

eliminada

atualizada

fechada

2. Filtrar a lista e definir os Estados da Classe;


aberta

H

Aberta

estado: =. aberta

do: Atualiza

Fechada

estado: =. fechada

do: Atualiza

CLASSE AGENCIA

fecha(horario, motivo)

abre


encerrada

3. Definir as transições possíveis entre os Estados;


Aberta para fechada

Fechada para aberta

4. Desenhar os Estados e as Transições de Estado possíveis;

5. Representar as atividades (eventos) que provocam cada Transição de Estado;

6. Representar os parâmetros (conteúdo da mensagem) que chegam nos eventos;

7. Detalhar a lógica interna (passos) de cada Estado.

Recomendações

• Somente construir o Diagrama de Estado para as Classes que possuem estado relevante;

• As Classes que possuem um Diagrama de Estados devem ter um atributo de estado (contém a várias situações);

• O Diagrama de Estado representa os estados de uma Instância da Classe de cada vez (não trata coleções);

• Nenhuma Instância pode ter dois estados correntes ao mesmo tempo;

• Um Estado pode ser invocado por vários Eventos, desde que possuam a mesma mensagem (mesmos parâmetros);

• Cada Evento identificado no Diagrama de Estado se transforma em uma Operação Pública (método de uma classe) no Diagrama de Classes;

• Os Métodos (lógica interna) associados aos Estados somente serão encapsulados no Modelo de Implementação como Operações Privadas.

Os seguintes padrões de nomenclatura devem ser observados nos projetos:

• Estado: devem ser utilizadas frases no gerúndio, expressões no particípio, ou em outros formatos, desde que transmitam a idéia de constância. Exemplo: Serviço Suspenso, Colaborador em Contratação. Não utilizar caracteres especiais e acentuação.

• Transição: devem ser utilizadas expressões que transmitam a idéia da ocorrência de um evento. Não utilizar caracteres especiais e acentuação.

Benefícios

• Auxilia na análise do comportamento das Classes (definição de operações ou métodos);

• Auxilia na definição das Regras que demonstram a dinâmica do negócio e que devem se tornar métodos ou operações a serem implementadas dentro do Sistema.


Diagrama de Seqüência


O Diagrama de Seqüência é um documento que tem como objetivo descrever a interação e a comunicação entre os objetos, ao longo do tempo. Em outras palavras, mostra como uma seqüência de mensagens é tratada (envio e recebimento) por vários objetos, com o objetivo de executar alguma função.

O Diagrama de Seqüência contém detalhes da implementação do Sistema, incluindo os Objetos e Classes usadas para implementá-lo e as mensagens passadas entre os objetos. Utiliza linhas verticais para representação do ciclo de vida do objeto e vetores horizontais para representar a passagem de mensagens entre os objetos.

O Diagrama de Seqüência mostra a seqüência de passos que devem ser realizados para cumprir a missão de cada Use Case solicitado por um Ator; envolve operações manuais, automatizadas e troca de mensagens entre Atores. A partir do Diálogo Sistema x Usuário do Projeto Conceitual pode-se detalhar o Diagrama de Seqüência para cada Caso de Uso.


São 2 os elementos básicos de um Diagrama de Seqüência:

• Objeto: representado através de um retângulo na parte superior (eixo horizontal) do Diagrama de Seqüência; corresponde às Classes existentes no Diagrama de Classes. O tempo (ciclo) de vida do objeto é representado por uma linha pontilhada vertical, desde o retângulo até o final do diagrama, em sua parte inferior.

• Mensagem: conjunto de dados e/ou de informações de controle que são enviadas de um objeto para outro, provocando neste último algum tipo de ativação. Uma mensagem pode ter associada condições e/ou interações (loops). As mensagens são representadas por flechas, e podem ser:

o Síncronas: mensagem implementada através da chamada de uma operação. O retorno para o objeto chamador somente poderá ser enviado quando esta operação tiver sido executada completamente;

o Assíncronas: mensagem cujo retorno poderá ser enviado a qualquer momento, mesmo que o objeto receptor não tenha executado completamente a operação resultante;

o Controles: mensagens que mostram simplesmente como o controle passa de um objeto para outro. Muitas vezes aparece como o retorno de uma mensagem síncrona.

Construção do Diagrama de Seqüência

1. Para cada Use Case, construir um Diagrama de Seqüência, identificando os Atores e as Classes envolvidas nele;

2. Identificar os passos necessários para tratar a Entrada até a invocação das Operações das Classes;

3. Demonstrar a invocação das Operações das Classes envolvidas; 4. Identificar os passos para tratar a Saída do Use Case;


Recomendações

• Elaborar um Diagrama de Seqüência para cada Use Case do Sistema.

Os seguintes padrões de nomenclatura devem ser observados nos projetos a serem desenvolvidos:

• Objetos: deve ser adotado o mesmo padrão utilizado na nomenclatura das classes do Diagrama de Classes. No Visio esse padrão é obrigatório.

• Mensagens: pode ser adotado o mesmo padrão utilizado na nomenclatura dos métodos do Diagrama de Classes, ou então qualquer nome que represente um conjunto de informações. No Visio esse padrão é obrigatório.

Benefícios

• Auxilia na análise da lógica interna para definir o funcionamento do Sistema;

• Auxilia no refinamento do Diagrama de Classes por permitir uma visão mais seqüencial da integração entre as Classes e Atores;

• Auxilia na definição das funcionalidades do Modelo de Implementação das Entradas e Saídas.

JOSE:USUARIOLIVRO:MATERIAIS

EMPRESTIMO:EMPRESTIMOSRESERVAS:RESERVAS

ConfirmaEmprestimo

PedeConfirmacao

Emprestar

Emprestimo

ItemDisponivel

ItemDisponivel

ConfirmaReserva

PedeConfirmacao

Reservar

Reservar

NaoDisponivel

VerificaDisponibilidade

Requisita


Diagrama de Colaboração


O Diagrama de Colaboração é um documento que, assim como o Diagrama de Seqüência, tem também como objetivo descrever a interação e a comunicação entre os objetos, mas com foco no espaço; retifica/ratifica os modelos já produzidos uma vez que não acrescenta nenhum conceito novo, mas permite uma visualização da análise sob outro ângulo.

Demonstra como as classes interagem pela troca de mensagens, apontando indícios de falhas na análise ou possibilitando refinamentos; por exemplo, classes muito dependentes ou falta de sincronismo entre classes. É uma visão alternativa do diagrama de Seqüência.


São 2 os elementos básicos de um Diagrama de Colaboração:

• Objeto: representado através de um retângulo. Os objetos do Diagrama de Colaboração são os mesmos já representados no Diagrama de Seqüência.

• Link: conexão entre dois objetos, que pode representar um fluxo de mensagem, ou simplesmente um papel que um objeto assume perante outro.

Como fluxo de mensagem, um link pode ter associado uma condição, uma numeração de seqüência, uma cláusula de iteração (loop) e um método a ser executado, sendo representado também através de flechas direcionadas conforme o destino indicado para as informações.

Como papel, apenas seu significado necessita ser mostrado; por exemplo, �� pode indicar que a instância de um objeto é visível porque está dentro do escopo global.

EMPRESTIMO:EMPRESTIMOS

RESERVAS:RESERVAS

LIVRO:MATERIAIS

JOSE:USUARIO

12: PedeConfirmacao 13: ConfirmaEmprestimo

11: Emprestar

6: PedeConfirmacao 7: ConfirmaReserva

5: Reservar

8: ItemDisponivel

2: VerificaDisponibilidade

10: Emprestimo4: Reservar1: Requisita

9: ItemDisponivel3: NaoDisponivel


Construção do Diagrama de Colaboração

Normalmente pode ser derivado automaticamente do Diagrama de Seqüência, através da ferramenta CASE utilizada. Valem, portanto, as mesmas recomendações para construção do Diagrama de Seqüência.

Recomendações

• O Diagrama de Colaboração deve representar pelo menos a troca de mensagens entre as Classes que tenham comportamento dinâmico (troca de eventos);

• Diagramas de Colaboração podem ser usados para mostrar interações complexas entre objetos.

• Principal diferença entre os Diagramas de Colaboração e de Seqüência:

o Diagrama de Colaboração: mostra o objeto real e suas ligações (a rede de trabalho dos objetos que estão colaborando), as quais em muitas situações facilitam o entendimento da interação.

o Diagrama de Seqüência: nele a seqüência do tempo é mais fácil de ver.

Que diagrama usar?

� Usar o Diagrama de Colaboração quando os objetos e suas ligações facilitam o entendimento da interação;

� Usar o Diagrama de Seqüência quando somente é preciso mostrar a seqüência.

Os seguintes padrões de nomenclatura devem ser observados nos projetos a serem desenvolvidos:

• Objetos: deve ser adotado o mesmo padrão utilizado na nomenclatura das classes do Diagrama de Classes.

• Links: pode ser adotado o mesmo padrão utilizado na nomenclatura dos métodos do Diagrama de Classes, ou então qualquer nome que represente um conjunto de informações.

Benefícios

• Auxilia na análise de dependência entre as Classes;

• Auxilia no refinamento do Diagrama de Classes, indicando Classes que potencialmente possam ser aglutinadas.


Modelo de Implementação

Diagrama de Pacotes


O Diagrama de Pacotes é um produto de modelagem de estruturas de informação, que tem como objetivo representar a organização de Sistemas, Subsistemas, Domínios e Camadas de Sistemas.

O Diagrama de Pacotes serve para mostrar como as Classes são divididas dentro de módulos; são diagramas lógicos e não necessariamente implicam numa divisão física de classes; agrupam os elementos modelados.

Os pacotes podem ser usados para apresentar diferentes visões da arquitetura do Sistema.

Recomendações

• O Diagrama de Pacotes é utilizado para modelar grupos de elementos e as diferentes visões da arquitetura de um sistema.

Benefícios

• Auxilia no controle da visibilidade dos elementos agrupados, possibilitando a visão externa do pacote;

x

ObjetosPersistentes

Sistema deJanelas

Bibliotecade GUI

Objetos DoProcesso

Controlador

1

1

1

1

1

1

1

1

11


• Auxilia na visualização dos grupos de elementos que podem ser manipulados como um todo, permitindo ter uma imagem de acesso aos elementos individualmente.

Diagrama de Componentes


O Diagrama de Componentes é um produto de modelagem de estruturas de informação, que tem como objetivo descrever as dependências entre os componentes físicos de software como bibliotecas DLL, arquivos de trabalho, arquivos executáveis, outros aplicativos, etc.

É utilizado para modelar a estrutura física do sistema.


São 3 os elementos básicos de um Diagrama de Componentes:

• Componente: é uma parte física com facilidade de reposição que permite a realização das funções do sistema.

• Interfaces: coleção de operações usadas para especificar o serviço de um componente.

• Relacionamentos

Biblioteca.CPPVbrum.DLL

Aplicativo.HAplicativo.DLLAplicativo.INI

Aplicativo.CPPAplicativo.EXE


Recomendações

• O Diagrama de Componentes é utilizado para se obter uma visão estática da implementação do sistema;

• O Diagrama de Componentes dá apoio ao gerenciamento da configuração das partes de um sistema composto por componentes que podem estar associados de várias formas;

• O Diagrama de Componentes é utilizado para modelar:

- Códigos fontes

- Versões de executáveis

- Banco de dados físico

- Adaptação de sistemas

Benefícios

• Visualização clara dos componentes a serem implementados;

• Facilita a reutilização de componentes já existentes;

• É base para o Diagrama de Distribuição.

Diagrama de Distribuição


O Diagrama de Distribuição é um documento de modelagem de estruturas de informação, que tem como objetivo mostrar como o software é distribuído no hardware; mostra os NÓS (plataformas), ou Nodes, e os links utilizados pelas aplicações.

É uma das formas para modelar os aspectos físicos de um sistema orientado a objeto. Mostra a configuração de Run Time de processamento dos Nós e dos componentes residentes em cada Nó. Envolve a modelagem de topologia de hardware na qual o sistema será executado.


São 2 os elementos básicos de um Diagrama de Colaboração:

• Nó: elemento físico que existe em tempo de execução do Sistema (Run Time); representa um recurso computacional possuindo geralmente alguma memória e alguma capacidade de processamento. Usado para modelar a topologia de hardware na qual o sistema é executado. Representa tipicamente um processador ou um equipamento no qual os componentes podem ser distribuídos.

• Relacionamento: representa a conexão física entre os Nós.


SERVIDOR DE APLICACAO

WWW.CLIENTE

SERVIDOR DE DADOS

EMPRESTIMO.HTMLComment

CONSULTA.HTML

Comment

GERENTE.HTML

Comment

CADASTRO.HTML

Comment

USUARIO.CLASS

Comment

MATERIAIS.CLASS

Comment

LIVROS.CLASS

Comment

REVISTAS.CLASS

Comment

SCRIPT.SQL

Comment

DAO-DataAccessObjects

Comment


Recomendações

• O Diagrama de Distribuição é utilizado para endereçar a distribuição, instalação e atualização das partes que constituem o sistema fisicamente;

• O Diagrama de Distribuição é recomendado apenas para sistemas multiplataforma fisicamente distribuídos em muitos processadores.

Benefícios

• Auxilia no controle de versionamento de componentes;

• Permite a visualização física dos componentes;

• Facilita o uso corporativo dos componentes;

• Auxilia na administração dos componentes.

Protótipo de Entradas e Saídas (Interface)


O Protótipo de Entradas e Saídas tem como objetivo representar a interação entre o usuário e o sistema, mostrando as entradas e saídas de informações.

Elementos Constituintes e Notações:

• Protótipo: representação visual de uma entrada ou saída do Sistema, podendo ser uma tela (formulário ou página) ou um relatório (em papel, meio eletrônico ou outra mídia).

Recomendações

Utilizar a ferramenta CASE ou um software de autoria de interfaces para desenhar o elemento de interface de Entrada ou Saída conforme formulário a seguir:


EMPRESA

PROTÓTIPO DE INTERFACE DE SISTEMA Entradas e Saídas

Identificação do Protótipo Projeto -

Componente -

Versão -

Responsável -

Data -

PROTÓTIPO

��


Projeto de Banco de Dados É responsável pela representação das estruturas físicas de informação que sustentam as transações do Sistema; representa a estrutura física do banco de dados ou dos arquivos que implementam o modelo lógico do armazenamento de dados.

Modelo de Banco de Dados (MDB)

Definição e Objetivo:

O MBD é um produto de Modelagem de Dados, que tem como objetivo descrever a estrutura dos dados armazenados pelo Sistema em um nível mais baixo de abstração, através de estruturas físicas únicas e dos relacionamentos entre elas.


São 2 os elementos básicos de um MBD:

• Tabela: conjunto de linhas e colunas, cujo ponto de intersecção representa um dado, dado-chave ou informação válida. Corresponde ao conjunto de atributos inerentes a uma entidade de dados do Modelo de Dados, sendo sempre representada por um retângulo:

• Relacionamento (Constraint): corresponde fisicamente aos relacionamentos do Modelo de

Dados. É utilizada para implementar a integridade dos dados no Banco de Dados, sendo representada por uma linha com os símbolos correspondentes representando as quantidades mínimas e máximas de ocorrências envolvidas (zero, uma ou várias) e a dependência de chaves.


Perfil Operacional


O Perfil Operacional tem como objetivo representar requisitos e características físicas relacionadas à operação do Sistema a ser desenvolvido, e pode funcionar como insumo para o planejamento das atividades de produção, assim como para a administração dos Servidores (Bancos de Dados, Web, Aplicação etc.) utilizados na solução.


O Perfil Operacional é constituído, basicamente, por 3 grupos de informações distintos:

• Volumes: mostra os volumes transacionais e de dados iniciais e o percentual de crescimento estimado em um prazo, distribuídos fisicamente, considerando-se a distribuição representada no Diagrama de Distribuição.

Ex.: Tabela PRODUTO: carga inicial – 100 registros

% crescimento – 10% mês

histórico – 2 anos

• Taxas de Acesso: mostra, para cada tabela, em seus respectivos locais físicos, as taxas por tipo de acesso (inserção, atualização, exclusão, consulta, etc.), dentro de uma determinada unidade de tempo.

Ex.: Tabela PRODUTO: inclusão – 20 ao ano

• Níveis de Concorrência: mostra, para cada tipo de processamento (transações on-line, transações batch e serviços de apoio), a quantidade média de sessões concorrentes e os níveis de serviço esperados pelo cliente para cada uma das transações.

Ex.: A transação on-line CONSULTAR PRODUTO terá uma quantidade média de 50 sessões concorrentes (alta), mas deve responder ao usuário em, no máximo, 10 segundos.


Modelo de Entradas e Saídas Estendido O Modelo de Entradas e Saídas Estendido é responsável pela especificação da lógica dos componentes que devem ser codificados.

Protótipo Estendido


O Protótipo Estendido tem como objetivo detalhar a lógica do protótipo homologado pelo usuário durante o Projeto Conceitual, permitindo a codificação dos componentes.


• Protótipo estendido: o protótipo físico em si.

• Especificação Lógica: especificação da lógica de funcionamento do componente.

EMPRESA

PROTÓTIPO DE INTERFACE DE SISTEMA Entradas e Saídas

Identificação do Protótipo Projeto -

Componente -

Versão -

Responsável -

Data -

PROTÓTIPO

��

LÓGICA

��


Especificação de Componentes


A especificação de componentes é a definição da lógica de um componente.

Recomendações

Documentar utilizando a ferramenta CASE ou o ambiente de desenvolvimento.


Plano de Testes


O Plano de Testes tem como objetivo demonstrar o que e como devem ser testados os componentes do Sistema, com enfoques individuais, de modularização e integração.


• Identificação do Plano de Teste: conjunto de informações para identificação do Plano de Testes: Projeto, Objetivo, Responsável e Versão.

• Configuração: configuração de hardware e software em que será efetuada o teste.

• Estratégia de Execução: estratégia para execução do teste do componente, do módulo ou do sistema integrado.

• Documentação de Apoio: documentos que podem ser utilizados para apoio do teste.

• Recursos e Treinamento: recursos que serão utilizados para o teste e treinamento que será necessário para sua realização.

• Fase: informações referentes à fase de teste a que se refere o plano (unitário, ou integrado). Tais informações são: Objetivo do Teste da Fase, Resultado Esperado, Método de Tratamento de Problemas, Data Prevista de Início, Data Prevista de Término, Data Real de Início e Data Real de Término.

• Tipo do Teste: informações referentes ao tipo do teste que será realizado (confiabilidade, exatidão, integridade, etc.). Tais informações são: Objetivo do Tipo do Teste, Resultado Esperado e Critérios de Teste.

• Plano de Teste: roteiro de teste do componente, do módulo ou do sistema. Este roteiro é uma descrição da ordem do teste, das conformidades que devem ocorrer e dos defeitos a serem evitados.

O Plano de Teste pode ser especificado conforme o formulário a seguir:


EMPRESA

PLANO DE TESTES

PROJETO -

OBJETIVO -

RESPONSÁVEL -

VERSÃO -

CONFIGURAÇÃO

ESTRATÉGIA DE EXECUÇÃO

DOCUMENTAÇÃO DE APOIO

RECURSOS E TREINAMENTO

FASE -

OBJETIVO -

RESULTADO ESPERADO -

MÉTODO DE TRATAMENTO DE PROBLEMAS

-

DATA PREVISTA DE INÍCIO: DATA PREVISTA DE TÉRMINO:

DATA REAL DE INÍCIO: DATA REAL DE TÉRMINO:

TIPO DE TESTE -

OBJETIVO DO TESTE -

RESULTADO ESPERADO -

CRITÉRIOS DE TESTE -

PLANO DE TESTE

��


Configuração de Ambientes

Definição e Objetivo A Configuração de Ambientes representa um conjunto de informações a respeito do ambiente de software utilizados nas fases de Testes e Implantação em Produção do Sistema.


• Tipo de Configuração: tipo do ambiente a que se refere a configuração (Teste, Homologação ou Produção).

• Configuração: conjunto de informações a respeito da configuração de hardware e software.

A Configuração de Ambiente pode ser especificada conforme o formulário a seguir:

EMPRESA

CONFIGURAÇÃO DE AMBIENTES

PROJETO -

RESPONSÁVEL -

TIPO DE CONFIGURAÇÃO

Config. Sistema Operacional – Servidores -

Config. Sistema Operacional – Clientes -

Config. Banco de Dados -

Config. Servidor Web -

Config. Aplicação – Componentes Servidor -

Config. Aplicação – Componentes Cliente -

CONFIGURAÇÃO DA REDE ARQUITETURA DA REDE

(Detalhes da Configuração)

�� !��


Modelos de Diagramas da UML

Diagrama de Use Cases

MODELO USE CASESystem Architect

Wed Feb 09, 2000 16:13

CommentBIBLIOTECA VIRTUAL

ANALISA EMPRESTIMO

CADASTRA MATERIAL

EMPRESTA MATERIAL

CADASTRA USUARIO

PESQUISA ASSUNTO

GERENTE

USUARIO

<<uses>>


Diagrama de Classes

MATERIAIS

AssuntoTituloCodigoResumoData_MaterialAutor

EmprestarDevolverProcurarReservarEditarExcluir

persistent

REVISTAS

LocalEditoraVolumeNumeroMesDestaquesestilo

CancelarEditarMostrar-Detalhes

persistent

USUARIO

NomeTelefoneSenhaEmailCodigo

ReservarCriarEliminarRecuperarAtualizar

persistent

RESERVAS

Data_ReservaData_ValidadeUsuarioCod_Material

CriarCancelarAvisar-Usuario

persistent

LIVROS

EditoraEdicaoPaginasLocal

Mostrar-DetalhesEditarCancelar

persistent

EMPRESTIMOS

Cod_MaterialUsuarioData_EmprestimoData_Devolucao

Novo

persistent

ARTIGOS

TituloAutor

CancelarEditar

persistent

MODELO CLASSESSystem Architect

Fri Feb 11, 2000 11:47

CommentBIBLIOTECA VIRTUAL

1

1

Eh Referente

1

1

Tem

1 1..*

1 1..*

1

0..*

Consulta


Diagrama de Estados

MODELO ESTADOSSystem Architect

Wed Feb 16, 2000 15:47

CommentDiagrama de Estados - Classe MATERIAIS

ATRASADO

DISPONIVEL

EMPRESTADO

RESERVADO

NaoDevolver[DataEmprestimo>Hoje] / AvisarUsuario

Disponibilizar[DataReserva<Hoje] / LiberaMaterial

Devolver[ExisteReserva] / AvisarUsuario

Devolver[SeAtrasado] / AvisarGerente

Retornar[ExisteReserva]

Retornar Emprestar

Emprestar


Diagrama de Seqüência

MODELO SEQUENCIASystem Architect

Wed Feb 23, 2000 15:55

Comment

JOSE:USUARIO LIVRO:MATERIAIS

EMPRESTIMO:EMPRESTIMOSRESERVAS:RESERVAS

ConfirmaEmprestimo

PedeConfirmacao

Emprestar

Emprestimo

ItemDisponivel

ItemDisponivel

ConfirmaReserva

PedeConfirmacao

Reservar

Reservar

NaoDisponivel

VerificaDisponibilidade

Requisita


Diagrama de Colaboração

MODELO COLABORACAOSystem Architect

Fri Feb 11, 2000 09:02

Comment

EMPRESTIMO:EMPRESTIMOS

RESERVAS:RESERVAS

LIVRO:MATERIAIS

JOSE:USUARIO 10: Emprestimo4: Reservar1: Requisita

9: ItemDisponivel3: NaoDisponivel

2: VerificaDisponibilidade

5: Reservar

8: ItemDisponivel

6: PedeConfirmacao 7: ConfirmaReserva

11: Emprestar

12: PedeConfirmacao 13: ConfirmaEmprestimo


Diagrama de Pacotes

MODELO PACOTESSystem Architect

Fri Feb 11, 2000 09:09

Comment

Persistentes

NegocioBiblioteca

Janelas


Diagrama de Componentes

MODELO COMPONENTESSystem Architect

Tue Feb 22, 2000 16:56

Comment

EMPRESTIMO.HTML

Comment


Comment

SCRIPT.SQL

Comment

REVISTAS.CLASS

Comment

LIVROS.CLASS

Comment

MATERIAIS.CLASS

Comment

USUARIO.CLASS

Comment

CADASTRO.HTML

Comment

GERENTE.HTML

Comment

CONSULTA.HTML

Comment


Diagrama de Distribuição

SERVIDOR DE APLICACAO

WWW.CLIENTE

SERVIDOR DE DADOS

EMPRESTIMO.HTMLComment

CONSULTA.HTML

CommentGERENTE.HTML

Comment

CADASTRO.HTML

Comment

USUARIO.CLASS

Comment

MATERIAIS.CLASS

Comment

LIVROS.CLASS

Comment

REVISTAS.CLASS

Comment

SCRIPT.SQL

Comment


Comment


Glossário Atributo ou Propriedade

Característica que qualifica um Objeto em si mesmo, independente dos outros objetos que o cercam. Contém o valor dos dados que descrevem cada Objeto na Classe.

Abstração Processo mental de definir um objeto conceitual a partir de objetos do mundo real que possuam os mesmos tipos de características e de comportamento.

Classe Conjunto de Objetos que possuem/compartilham os mesmos atributos (propriedades e dados), comportamentos (operações e métodos) e relacionamentos (características).

Classe dos Atributos

São características descritas para todas as instâncias de uma Classe. Correspondem às colunas de uma tabela de dados.

Estado Representa as condições dos objetos em um determinado momento no tempo.

Evento Representa incidentes que causam movimentação nos objetos de um estado para outro.

Instância Cada objeto dentro de uma determinada classe.

Mensagem Conjunto de dados e/ou informações de controle (parâmetros) que são enviadas de um objeto para outro, provocando algum tipo de ativação.

Método Implementação específica de uma operação da classe; é a lógica interna de uma operação (conjunto de passos para que a operação seja realizada).

Objeto Qualquer coisa existente e perceptível que possui características próprias e comportamento previsível.

Operação Toda ação que pode ocasionar uma mudança nas características do objeto; é chamada via mensagem; é composta pelo nome e parâmetros. De modo geral uma operação é capaz de atualizar, incluir, consultar, atualizar o estado de um objeto.

Relacionamento Representa a forma como as Classes de Objetos se reconhecem entre si; determina o tipo de relação que um objeto tem com outro.

Transição de Estado

Movimentação de um estado para outro.


Bibliografia Furlan, José Davi Modelagem de Objetos através da UML, São Paulo: Makron Books, 1998

Fowler, Martin UML Essencial, Porto Alegre: Bookman, 2000

Rumbaugh, J.; Jacobson, I.; Booch G. The Unified Modeling Language Reference Manual, Addison Wesley Longman, Inc., 1999

Rumbaugh, J.; Jacobson, I.; Booch G. The Unified Modeling Language User Guide, Addison Wesley Longman, Inc., 2001

Booch, Grady Object-Oriented Analysis and Design With Applications, Addison-Wesley Publishing Company, 1994

projeto fÍsico de sistemas de informaÇÃo · projeto físico de sistemas de informação –...

Documents