modelagem oo com uml - dainf/departamento acadêmico de...

Modelagem OO com UML

Vítor E. Silva Souza

([email protected]) http://www.inf.ufes.br/~ vitorsouza

Departamento de Informática

Centro Tecnológico

Universidade Federal do Espírito Santo

Modelos •  Maneira de projetar, comunicar, documentar, etc. soluções computacionais;

•  Diversos níveis, por exemplo: – Ontologias (modelos genéricos, de domínio); –  Requisitos (foco em um problema); –  Projeto / arquitetura (foco em uma solução).

•  Essenciais para o desenvolvimento de soKware;

•  Assim como o desenvolvimento, também seguem os paradigmas (estruturado, OO, etc.).

Maio 2013 Modelagem Conceitual com UML 2

Unified Modeling Language •  Padrão “de facto” para especificar, visualizar, documentar e construir artefatos de um sistema desenvolvido sob o paradigma Orientado a Objetos;

•  Nasceu na RaZonal SoKware, desde 1997 é um padrão da Object Management Group (OMG);

•  Reconhecido pela ISO em 2000; •  Teve origem em três outros métodos:

– OMT (Rumbaugh et al., 1994); – Método de Booch (Booch, 1994); – Método OOSE (Jacobson, 1992).

•  Versão atual: 2.4.1 (2011).


Diagramas da UML

•  de Casos de Uso; •  de Classes; •  de Objetos; •  de Estrutura Composta; •  de Sequência; •  de Comunicação; •  de Estados; •  de AZvidades; •  de Componentes;

•  de Implantação; •  de Pacotes; •  de Interface Geral; •  de Tempo.


Modelagem Unificada? •  A notação é unificada: quase todo desenvolvedor de soKware conhece ao menos parte da UML;

•  A decisão de qual artefato (diagrama) produzir, porém, depende do processo definido para o projeto; –  Projetos diferentes, necessidades diferentes.

•  Pode ser uZlizada em diferentes processos de desenvolvimento orientados a objetos, em todas as etapas do ciclo de desenvolvimento. –  Exemplo: domínio, requisitos, arquitetura, etc.


Exemplo: Diagrama de Casos de Uso

•  Modela as funcionalidades do sistema;

•  Captura ipicas interações usuário – sistema;

•  Usuários são atores; •  Atores e casos de uso são associados;

•  Cada caso é descrito em detalhes separadamente.


Exemplo: o Diagrama de Classes


Classe

Nome Atributos Operações

Classe Abstrata

Herança

Agregação

Associação (e suas cardinalidades)

Classe Associativa

Representa as classes relevantes (abstração!) para o domínio, problema ou solução.

Exemplo: Diagrama de Estados

•  Representa diferentes estados em que um objeto pode estar;

•  Foco em uma classe de objetos específica (no exemplo, Pedido);

•  Captura a dinâmica de um sistema, com foco numa classe.


Exemplo: Diagrama de Sequência •  Também captura a dinâmica de um sistema; •  Porém, o foco é em uma função específica.


MODELAGEM ESTÁTICA Modelagem Conceitual com UML


Modelagem estáZca •  Centrada no diagrama de classes:

–  IdenZficação de classes; –  Especificação de hierarquias de generalização / especialização;

–  IdenZficação de subsistemas; –  IdenZficação de associações e atributos.


Lembre-se: na orientação a objetos modelamos classes, portanto este diagrama é central!

Classes: níveis de abstração •  Ontologias:

– Modelagem de conceitos de um domínio, relacionando-‐os com conceitos fundamentais;

•  Análise (de requisitos) de sistemas: – Modelagem de conceitos específicos do problema analisado;

•  Projeto (arquitetural) de sistemas: – Modelos de aplicação (serviços), interface gráfica com o usuário, persistência de dados, etc.

– Modelos de domínio mais detalhados.


Representação de classes


Nome da Classe

<Lista de atributos>

<Lista de operações>

Se estiver em itálico, a classe é abstrata.

Sintaxe: <escopo> <nome> : <tipo> = <valor default> Escopo:

- privado + público # protegido

Sintaxe: <escopo> <nome> (<parâmetros>) : <tipo> <parâmetros> = lista de pares “<nome> : <tipo>”, separada por vírgula.

Representação em UML

Dependendo do nível de abstração, alguns detalhes podem ser omitidos (ex.: tipo e escopo na fase de análise).

Herança (inheritance) •  Devem modelar relações “é-‐um-‐Zpo-‐de”; •  Subclasses devem suportar toda a funcionalidade das superclasses e possivelmente mais;

•  Funcionalidade comum a diversas classes deve estar o mais alto possível na hierarquia;

•  Classes abstratas não podem herdar de classes concretas.

Maio 2013 Modelagem Conceitual com UML 14 G

eneralização

Espe

cial

izaç

ão

Separação em subsistemas / módulos •  Projetos grandes podem conter centenas de classes e estruturas diversas;

•  Divisão das classes em pacotes: –  Coleção de classes que colaboram entre si; –  Conjunto coeso de responsabilidades; –  “Caixa preta”.

•  Vantagens: –  Facilita o entendimento para leitores; – Auxilia na organização de grupos de trabalho; – Organiza a documentação; –  Em suma, facilita a manutenção.


Pacotes (packages) •  Podem ser usados para organizar diversos Zpos de elementos de modelos, inclusive diagramas inteiros;

•  Muito uZlizados para organizar classes em módulos, da mesma forma que será feito em Java/C++;

•  É possível representar relação de dependência entre pacotes:


Associações (associaZons) •  Relacionamento entre classes é representado por associações, agregações e composições;

•  Associações podem indicar cardinalidade (cardinality):


Um e somente um.

Objetos da ClasseA podem se relacionar com no mínimo zero e no máximo três objetos da ClasseB.

Nenhum, um, ou vários.

Papéis (roles) •  Indicam o papel que a classe desempenha na associação (são usados substanZvos);

•  É opcional, usado quando melhora o entendimento do modelo;

•  Sintaxe: <escopo> <nome>.


Classes associaZvas (associaZon class) •  UZlizadas quando a associação possui atributos; •  Comuns em relações n-‐para-‐n.


Relacionamentos recursivos •  Perfeitamente legais; •  Geralmente pedem definição de papéis.


Associações n-‐árias •  Associações entre três ou mais classes; •  Extremamente raras, muitas vezes as ferramentas CASE nem dão suporte;

•  Podem ser subsZtuídas por uma nova classe e N associações.


Agregação e composição •  Já estudadas anteriormente... •  Adicionam um losango à sintaxe, na extremidade da classe que representa o todo:


Atributos (ayributes) •  Atributos são informações de estado (propriedades) para o qual cada objeto em uma classe tem seu valor;

•  Muito similares às associações: –  Como atributos têm um Zpo, podemos considerar que são associações com um Zpo;

–  Para Zpos primiZvos definimos atributos, do contrário modelamos uma associação;

–  Em úlZma instância, associações e atributos são implementados da mesma forma;

– Atributos e associações definem uma classe.


Especificação de atributos •  Escolha um nome com significado; •  Siga um padrão de nomenclatura; •  Inclua-‐o na modelagem de classes:


Atributos e hierarquias de classe •  Atenção à hierarquias de classes:

– Atributos genéricos ficam mais acima na hierarquia; –  Por outro lado, se ele não se aplica a algumas subclasses, deve ser trazido “para baixo”, somente para as classes apropriadas.

•  Revisão da hierarquia: – Descoberta de atributos nos leva a um melhor entendimento, o que possivelmente implicará revisão de hierarquias.


Exemplo

Arquivopathnome

InfoNaoDigitallocalizacao

GerenciadtIniciodtFim

Essa classe de associação guarda as relações de gerência entre um funcionário e uma área de um Job. Se dtFim é nulo, o funcionário é o gerente atual daquela área de Job. Só pode haver um gerente atual por área de Job.

Essa classe de associação guarda as relações de designação entre um funcionário e uma área de um Job. ehAceito indica que o funcionário aceitou trabalhar naquela área. Se dtFim é nulo, o funcionário ainda está designado àquela área do Job. Caso contrário, registra o período em que o funcionário trabalhou naquela área de job.

DesignacaodtEnviodtRecebimentodtIniciodtFimtextoehAceitomotivoRejeicao

obterTexto()aceitar()rejeitar()atribuirDtInicio()atribuirDtRecebimento()

Areanome

AreaJobprazostatus

criar()atribuirGerente()obterNovasDesignacoes()

0..n1 0..n1

Funcionario(f rom ControleInterno)

0..n

0..n

0..n

+Gerente0..n0..n

0..n

0..n

+Designado

0..n

0..n

0..n

0..n

+Função

0..n

InformacaoAreaJobdtInsercaodescricao

0..n

1

0..n

1

1

0..n

1

0..n


Modelo de domínio Análise de requisitos Sistema de gerência de “jobs” em uma agência publicitária.

Exemplo


Modelo de domínio Projeto arquitetural Sistema de gerência de “jobs” em uma agência publicitária.

Exemplo


JanCadastrarFuncionario

JanCadastrar(f rom UtilitarioInterf aceGraf ica)

javax.swing.JOptionPane(f rom UtilitarioInterf aceGraf ica)

Modelos de interface com o usuário e de controle Projeto arquitetural do mesmo sistema anterior.

Exemplo

DP_ControleJob

GD_ControleJob

GT_ControleJob

IU_ControleJob

UtilitarioPessoa(from Utilitario)

UtilitarioInterfaceGrafica

(from Utilitario)

GT_ControleArea(from ControleArea)

GT_Comunicacao(from Comunicacao)

UtilitarioGerenciaDados

(from Utilitario)

DP_ControleInterno(from ControleInterno)

DP_ControleArea(from ControleArea)


Diagrama de pacotes. Projeto arquitetural do mesmo sistema anterior.

MODELAGEM DINÂMICA Modelagem Conceitual com UML


Comportamento dinâmico •  Os diagramas de classes representam apenas elementos estáZcos, dados;

•  É preciso, ainda, representar o comportamento da aplicação em função do tempo e de eventos específicos;

•  Modelar o comportamento: –  Indica como o sistema irá responder a eventos ou esimulos externos;

– Auxilia o processo de descoberta das operações das classes do sistema.


Modelos da UML •  Diagramas de Estados:

– Descrevem os estados possíveis pelos quais um parZcular objeto pode passar e suas transições, esimulos e aZvidades;

–  Foco em uma classe específica. •  Diagramas de Interação:

– Descrevem como grupos de objetos colaboram entre si em um certo comportamento;

–  Envolve várias classes, foco em um comportamento (funcionalidade) específico.


Diagrama de Máquina de Estados •  Similar ao Diagrama de Transição de Estados (DTE), do paradigma Estruturado;

•  Construído para uma única classe; •  Mostra o comportamento dos objetos desta classe ao longo do tempo: –  Estados possíveis; –  Eventos que alteram estado; –  CaracterísZcas de cada estado; –  Etc.


Notação


Estado Inicial Estado Final

Transição

Estado

Estados •  Nome: deve descrever claramente o estado; •  AZvidades:

– De entrada: ocorrem ao entrarmos no estado; – De saída: ocorrem ao sairmos do estado; –  Convencional: ocorrem enquanto o objeto esZver naquele estado.


Estados inicial e final •  Os estados ligados ao estado inicial são aqueles nos quais o objeto pode estar logo quando for construído; –  Se houver mais de um, deve-‐se especificar condições de entrada em cada estado;

•  Os estados ligados a um estado final são aqueles dos quais o objeto não mais sairá; – Não é obrigatório ter e pode ter mais de um; – Um estado ligado a um estado final não pode ter transições para outros estados.


Transições •  Indicam a possibilidade de ir de um estado a outro;

–  Evento: evento externo que moZvou a transição; –  Condição de guarda: condição necessária para efetuar a transição (além do evento);

– Ação: ação realizada durante a transição.


Ação x aZvidade •  Ação x aZvidade convencional:

– Uma ação ocorre durante a transição (ela é atômica); – Uma aZvidade ocorre enquanto o objeto permanece no estado (quando ela acabar, ele muda de estado);

•  Ação x aZvidades de entrada/saída: –  Caso só haja uma transição de entrada/saída, não há diferença na práZca.


Exemplos


Ao ser criado, o objeto da classe em questão encontra-se no estado E-1.

Se o objeto estiver no estado E-1 e ocorrer o evento E, se a condição C = true, ocorre a ação A e o objeto passa para o estado E-2.

Enquanto estiver no estado E-1, o objeto realiza a atividade A. Ao terminar a atividade A, automaticamente ele muda para o estado E-2.

Exemplo


Diagramas de interação •  Ajudam a compreender e capturar o fluxo global de controle;

•  Modelam um conjunto de objetos e as mensagens que trocam;

•  Foco em uma funcionalidade específica (caso de uso); •  Dois Zpos de diagrama (duas visões):

– Diagrama de Sequência (temporal): foco no tempo e no controle;

– Diagrama de Colaboração (estrutural): ênfase na organização dos objetos.


Diagrama de sequência – notação


FLUXO

Retorno

Linha de vida do objeto Marcador de iteração

Escopo

Classe Objeto

Exemplo


referência a um objeto

Exemplo


Diagrama de colaboração – exemplo


h1p://nemo.inf.ufes.br/


modelagem oo com uml - dainf/departamento acadêmico de...

Documents