• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Umlv4 090813182632-phpapp02
 

Umlv4 090813182632-phpapp02

on

  • 146 views

UML

UML

Statistics

Views

Total Views
146
Views on SlideShare
146
Embed Views
0

Actions

Likes
1
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Umlv4 090813182632-phpapp02 Umlv4 090813182632-phpapp02 Document Transcript

    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UMLUML - Linguagem de Modelagem Unificada Autor: Rildo F. Santos (rildosan@uol.com.br)
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 2 Conteúdo Parte 1: - Introdução a Orientação a Objeto Parte 2: - Introdução a UML Parte 3: - Diagramas da UML Parte 4: - Estudo de Caso - Exercício Apêndices: - Notação UML - UML 2.0
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 3 Palavra inicial A UML é padrão de mercado (www.omg.org/uml) que representa as melhores práticas da engenharia de software em modelagem de software; A UML permite que desenvolvedores visualizem o software através modelos e de um conjunto de diagramas; A modelagem visual facilita o entendimento e a comunicação do 'quê' precisa ser feito e 'como' deve ser feito o software; Os diagramas oferecem a padronização, que é necessária quando trabalhamos com grandes equipes de desenvolvedores ou com fornecedores; Neste treinamento apresentaremos todos os diagramas, elementos e a semântica da Linguagem de Modelagem Unificada; O treinamento: Começa sendo demonstrado uma introdução a orientação a objetos com objetivo de fazer um alinhamento de conhecimento da Orientação a Objetos. Depois é apresentado a UML, semântica e todos os diagramas (da versão 1.5) Também será exibido em estudo de caso com propósito de mostrar como é feito a modelagem visual de software com UML. Será utilizada uma ferramenta de modelagem visual para ajudar o aprendizado da UML.
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 4 Introdução a Orientação a Objetos Objetivo desta parte: É apresentar e discutir uma introdução a Linguagem de Modelagem Unificada versão 1.5.
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 5 Orientado a Objetos Introdução a Orientação a Objetos Os sistemas projetados atualmente são maiores, mais complexos e sujeitos a constantes alterações e adaptações aos diversos ambientes computacionais. Através do encapsulamento de informações, a reutilização de esforços empregados em projetos anteriores e a modificação do sistema se tornaram mais fáceis. Orientação a Objetos: Um problema sempre define ou está contido em um domínio (sujeito a leis da física, da matemática, do direito, do mercado financeiro e por ai a fora). Assim a primeira resposta a buscar no desenvolvimento de um sistema em computação é a construção de um modelo que coloque em termos de algoritmos o domínio da aplicação. Pensando num modelo de objetos, numa abordagem de alto nível de abstração há três fases: Projeto e Modelagem UML Implementação Linguagem Java Metodologia Análise Orientação a Objetos Análise: Discute o porque, o que (com quais informações e para quais serviços) se deve fazer Projeto: O Como fazer, de forma a ficar manutenível; O mapeamento em linguagem processável pelo computador
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 6 O Método Orientação a Objetos A metodologia Orientação a Objetos é baseada em noções, consideradas intuitivas ao ser humano, tais como: objetos e atributos, classes e membros, estruturas e componentes, ação e reação. Os métodos de desenvolvimento de software anteriores ao surgimento desse paradigma organizam a especificação de um sistema de acordo com suas funções ou com os dados manipulados. Geralmente, esses métodos apresentam dificuldades na transição da representação do sistema em uma fase para outra do processo de desenvolvimento (da Análise para o Projeto e, do Projeto para a Implementação). Em um sistema orientado a objetos, os dados e todas as operações (funções), que manipulam esses dados, são agrupados em uma única estrutura: os objetos. Desde o início do desenvolvimento desses sistemas e, em todas as suas fases, o analista trabalha com o mesmo elemento de abstração, os objetos. Introdução a Orientação a Objetos Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 7 As classes são as partes mais importantes de qualquer sistema orientada a objetos. Usamos as classes para capturar o vocabulário do sistema que está em desenvolvimento. Essas classes podem incluir abstrações que são parte do domínio do problema, assim como as classes que fazem uma implementação. Podemos usar ainda as classes para representar itens de software, de hardware e até itens que sejam somente conceituais. Exemplo: A classe Pessoa deverá ter atributos e métodos comuns Pessoa Nome Idade GetNome GetIdade Nome da Classe Atributos Métodos Os nome deverão ser identificadores únicos em conjunto de classes, este devem ser substantivos. Exemplo: Produto. Tipos de Classes: • Classe Concreta • Classe Abstrata O que é uma Classes? “Uma classe descreve um conjunto de objetos com propriedades e comportamentos semelhantes e com relacionamentos comuns com outros objetos” Classe Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 8 Exemplo: A classe Pessoa. Classe concreta. public class Pessoa { //Atributos private String nome; private int idade; //métodos public String getNome(){ return nome; } public void setNome(String nome){ this.nome = nome; } public int getIdade(){ return idade; } public void setIdade(int idade){ this.idade = idade; } } Classe Concreta: Uma classe que tem assinatura e a implementação de métodos. Exemplo de diagrama de classe usando Rational Rose (notação Unified) Classe Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 9 Exemplos de Objetos: O que são Objetos ? São qualquer coisa na natureza que possua propriedades (características) e comportamentos (operações). Exemplo: uma pessoa, uma cão e etc Orientação a Objetos: O termo orientação a objetos significa organizar o mundo real como uma coleção de objetos que incorporam estrutura de dados e um conjunto de operações que manipulam estes dados. Estrutura de um objeto Objetos combinam propriedades (atributos) e comportamentos (operações ou métodos). Propriedades Comportamentos Bonita Jovem Inteligente Andar Correr Falar Chorar Dançar Objeto: Pessoa Objetos Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 10 public class CalculaData { private int day, month, year; public float calcDays(int age ) { return 365.25F * age; } } Métodos método Métodos são os comportamentos ou as funções do objeto. A declaração é feita da seguinte forma: < modificador > < tipo de retorno > < nome > ( < lista de argumentos > ) < bloco > < modificador > -> segmento que possui os diferentes tipos de modificações incluíndo public, protected, private e default (neste caso não precisamos declarar o modificador). < tipo de retorno > -> indica o tipo de retorno do método. < nome > -> nome que identifica o método. < lista de argumentos > -> todos os valores que serão passados como argumentos. Exemplos: public void somaDias (int dias) { } private int somaMes(int mês) { } protected String getNome() { } int getAge(double id) { } Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 11 public class Disciplina { private int cargaHoraria; private String nome; public Disciplina(String nome, int cargaHoraria){ this.nome = nome; this.cargaHoraria = calcCargaHoraria(cargaHoraria); } public String getNome(){ return nome; } public int getCargaHoraria(){ return cargaHoraria; } public int calcCargaHoraria(int qdeHoras) { int horasPlanejamento = (int) ( qdeHoras * 0.1); return cargaHoraria = horasPlanejamento + qdeHoras; } } Atributos Variáveis temporárias Atributos e variáveis (Linguagem Java) Os atributos são pertencentes a classe, eles podem ser do tipo primitivo ou referência (objetos), os seus modificadores podem ser: public, private, protected ou default. O ciclo de vida destes atributos estão vinculados ao ciclo de vida da classe. Variáveis Locais: São definidas dentro dos métodos. Elas têm o ciclo de vida vinculado ao ciclo do método, também são chamadas de variáveis temporárias Modificador Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 12 O que é abstração? Podemos dizer abstração é generalização. Qual é a função da abstração ? A função da abstração é capturar as propriedades e os comportamentos essenciais, como se fosse uma fatoração, desta forma determina-se o que é importante e o que não é. Aeronave Caça Helicóptero Passageiros Mamífero Vaca Urso Cavalo Para discutirmos sobre classes abstratas é necessário falarmos sobre a abstração de dados. As classes Aeronave e Mamífero neste caso são abstratas e ambas representam um domínio. Abstração de Dados: Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 13 Uma operação abstrata só determina a existência de um comportamento não definindo uma implementação. Classes Abstratas - Exemplo: Classes Abstratas Uma classe abstrata é uma classe que: • Provê organização • Não possui “instances” • Possui uma ou mais operações (métodos) abstratas Pessoa Pessoa Física Pessoa Jurídica getNome() getNome() getNome() Classe Abstrata Funcionário Analista Programador Classe concreta Classe concreta Classe Abstrata Abstração de Dados: Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 14 Um relacionamento é a conexão entre itens. É representado graficamente como um caminho, que tem tipos diferentes de linhas para distinguir os tipos de relacionamentos. Ao construir as abstrações, descobrimos que são poucas as classes que trabalham sozinhas. Em vez disso, a maioria das classes colaboram com outras classes de várias maneiras. Portanto, quando estamos modelando, devemos identificar as classes, atributos, métodos e relacionamentos. Existem alguns tipos principais de relacionamentos entre classes e objetos: • Herança • Agregação Veja a definição de relacionamento: Exemplo: Hierarquia de Classes Pessoa Aluno Funcionário Professor Pessoal Administrativo Terceiro Professor Autônomo Pessoal Operacional SubClasses SuperClasse Relacionamento: 1 - Pessoa é a SuperClasse de Terceiro, Aluno e de Funcionário, estas são subclasse de Pessoa. 2 - Terceiro e Funcionário são SuperClasse de Professor e Pessoal Administrativo e de Professor Autônomo e Pessoal Operacional respectivamente. E estas são subclasse de Terceiro e Funcionário. Relacionamento Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 15 Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e comportamento de elementos mais gerais, 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 “pai” proporciona a funcionalidade que é comum a todas as suas classes derivadas, filhas, enquanto que uma classe derivada proporciona a funcionalidade adicional que especializa seu comportamento. Exemplo: Graduação Pós-Graduação Curso Universitário Especialização Extensão Hierarquia de Classes Podemos dizer que Graduação é tipo de Curso Universitário, assim como Curso de Especialização ou de Extensão. extends extends Herança Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 16 Exemplo: Implementação- Pessoa, Aluno, Terceiro, Funcionário public abstract class Pessoa { protected String idPessoa; protected int idade; protected String nome; public Pessoa(String nome) { this.nome = nome; } public abstract String getNome(); public void setidPessoa() { } public abstract int getIdade(); public void setIdade(int idade) { } } public class Terceiro extends Pessoa{ private int codigoTerceiro; public Terceiro(String nome) { super(nome); } public int getIdade() { return 0; } public String getNome() { return ""; }; } public class Funcionario extends Pessoa{ private int codigofuncionario; public Funcionario(String nome) { super(nome); } public int getIdade() { return 0; } public String getNome() { return ""; }; } Professor Autônomo Pessoal Operacional Professor Pessoal Administrativo Herança public class Aluno extends Pessoa{ public Aluno(String nome) { super(nome); } public int getIdade() { return 0; } public String getNome() { return ""; }; } Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 17 Pessoa AlunoTerceiro public class ProfessorAutonomo extends Terceiro{ public ProfessorAutonomo( String nome) { super(nome); } } public class PessoalOperacional extends Terceiro{ public PessoalOperacional( String nome) { super(nome); } } public class Professor extends Funcionario{ public Professor( String nome) { super(nome); } } public class PessoalAdministrativo extends Funcionario{ public PessoalAdministrativo( String nome) { super(nome); } } Funcionário Exemplo de Herança: Implementação: ProfessorAutonomo, PessoalOperacional, Professor e Pessoal Administrativo Herança Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 18 A herança múltipla é quando uma classe tem mais que uma Superclasse associada e que herde as características de todas elas. Veja a figura abaixo: Pessoa Pessoa JurídicaPessoa Física <<interface>> Mamífero Relacionamento: Pessoa Física é tipo de pessoa, mas também é mamífero. Na linguagem Java: A Herança múltipla é somente permitida por contrato, neste caso a Mamífero é uma Interface, podemos dizer que é tipo especial de classe, que não pode ter métodos implementados, apenas as assinaturas. Herança Múltipla <<interface>> Mamífero Interface: O que é interface ? Interface é um contrato entre o cliente, que pode ser classe concreta ou abstrata, e a interface. Este contrato é garantia que o métodos assinados na interface serão implementados na classe cliente. Nota: Na interface também podemos declarar constantes (public static final). interface Product { String getName (); double getCost (); } Superclasse Superclasse Exemplo de Interface Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 19 Exemplo: Implementação da classe Pessoa, PessoaFisica e PessoaJuridica e a interface Mamifero public abstract class Pessoa { protected String idPessoa; protected int idade; protected String nome; public Pessoa(String nome) { this.nome = nome; } public abstract String getNome(); public abstract int getIdade(); public void setIdade(int idade){ } } public class PessoaJuridica1 extends Pessoa { public PessoaJuridica1(String nome) { super(nome); } public int getIdade() { return 0; } public String getNome() { return ""; }; } public interface Mamifero { final int qdeOlhos=2; public int getQdePernas(); } public class PessoaFisica1 extends Pessoa implements Mamifero { public PessoaFisica (String nome) { super(nome); } public int getQdePernas(){ return 2; } public String getNome(){ return “”; } public int getIdade(){ return 0; } } Exercício: 1 - Podemos implementar a herança múltipla na Classe Pessoa? Por que ? 2 - Por que somos obrigado a assinar ou implementar os métodos da Interface Mamifero na classe PessoaFisica Herança Múltipla implements extends extends Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 20 É uma proteção adicional dos dados do objeto de possíveis modificações impróprias, forçando o acesso a um nível mais baixo para tratamento do dados. Operações/métodos/interface pública Dados/Atributos/propriedades privada Encapsulamento (“data hiding”) Encapsulamento é definido como uma técnica para minimizar dependências entre “módulos” através da definição de interfaces externas. Também conhecido como: O fenômeno da “caixa preta” Encapsulamento public class Empregado { private double salario; public Empregado(){ salario=0.00; } public double getSalario(){ return this.salario; } } O atributo salario somente poderá ter um valor atribuído ou alterado, através de método público. Através do método getSalario, que tem modificador public, podemos manipular ou recuperar o valor do atributo salario. Classe Empregado e método getSalario O atributo salario private double salario; Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 21 A interface (pública) de um objeto declara todas as operações permitidas (métodos) Todo o acesso aos dados do objeto é feito através da chamada a uma operação (método) da sua interface. Encapsulamento - 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 Encapsulamento public class Gerente1 extends Empregado { private double bonus = .15; public double getSalario(){ //referência ao método getSalario return super.getSalario() + (super.getSalario()*this.bonus); } } public class Empregado { private double salario; public Empregado(){ salario=0.00; } public double getSalario(){ return this.salario; } } private double salario; Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 22 Definição: “Polimorfismo” é uma operação que pode assumir múltiplas formas, a propriedade segundo o qual uma operação pode comportar-se diferentemente em classes diferentes” (Rumbaugh) O polimorfismo é o responsável pela extensibilidade em programação orientada a objetos. Polimorfismo overloading overriding Overloading: Possibilidade de reúso do nome do método para diferentes implementações, em tempo de execução, a aplicação, escolherá o método adequado para cada chamada, veja o exemplo. TesteSoma Soma somar(int a, int b) somar(float a, float b) somar(char a, char b) somar(long a, long b)) Para cada tipo de dados existe um método, o reúso do nome do método é permitido, entretanto a lista de argumentos deve ser diferente, veja o exemplo acima: o método somar é definido várias vezes, entretanto com a lista de argumentos diferente, desta forma evitaremos problemas como ambigüidade. Polimorfismo Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 23 public class EmpregadoExemplo { private double salario; public void setSalario(int diastrabalhados, double valorhora ){ this.salario = diastrabalhados * valorhora * 8; } public double getSalario(){ return this.salario; } } public class Engenheiro extends EmpregadoExemplo { public static void main(String args[]) { Engenheiro eng = new Engenheiro(); eng.setSalario(22, 35.00); System.out.println(eng.getSalario()); } } O método setSalario é herdado da Superclasse (Empregado), entretanto para cada cargo (tipo de empregado) ele tem uma implementação diferente. Por exemplo: - Para Engenheiro e Secretária salário = (Dias Trabalhados x Valor hora) - Para Gerente salário = (Dias Trabalhados x Valor hora) + Bônus - Para Diretor salário = (Dias Trabalhados x Valor hora) + Bônus + Participação nos lucros. Overrinding - Exemplo: Empregado setSalario() getSalario() Engenheiro getSalario() Gerente getSalario() Diretor getSalario() Secretária getSalario() Polimorfismo Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 24 Overrinding Uma subclasse pode mudar o comportamento herdado da Superclasse, ou seja, um método herdado poderá ser alterado. Veja o exemplo abaixo: O método getSaldo é herdado da Superclasse (Conta Bancária), entretanto para cada tipo de Conta ele tem uma implementação diferente. Por exemplo: - Para apurar o saldo da Conta Corrente saldo atual = (soma dos depósitos + saldo anterior) - saques Para a conta poupança seria saldo atual = (soma dos depósitos + saldo anterior + juros) - saques Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior + juros) - resgates - ir Conta Bancária getSaldo() Conta Corrente getSaldo() Conta Poupança getSaldo() Investimentos getSaldo() Exercício: Faça a implementação das classes acima. Polimorfismo Orientado a Objetos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 25 Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 26 Visão de Projeto Funcionalidade Vocabulário Visão da Implementação Codificação Montagem Visão do Processo Desempenho Escalabilidade Throughput Visão da Implantação Topologia do Sistema Distribuição Instalação Conceitual Físico Visão de Caso de Uso Visão 4 + 1 Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 27 • A visão do caso de uso abrange os casos de usos que descrevem o comportamento do sistema conforme é visto pelos seus usuários finais, analista e pessoal de teste. Essa visão não especifica realmente a organização do sistema de softwasre. Porém , ela existe para especificar as forças que determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estáticos dessa visão são representados em diagramas de caso de uso, enquanto os aspectos dinâmicos são representados em diagrama de interação., diagrama de gráfico de estados e diagrama de atividades • A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do problema e de sua solução. Essa perpectiva proporciona principalmente um suporte para os requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários finais. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de objetos; os aspectos dinâmicos são captados em diagramas de interações, de estados e de atividades. Visão de Caso de Uso Visão de Processo Introdução a UML Visão 4 + 1
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 28 • A visão do processo abrange os threads e os processos que formam os mecanismos de concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões de desempenho, à escalabilidade e ao throughput do sistema. Com a UML, os aspectos estáticos e dinâmicos dessa visão são capturados nos mesmos tipos de diagrama da visão do projeto, mas o foco voltado para as classes ativas que repesentam esses threads e processos. Threads = Linhas de execução em paralelos, estas linhs podem ser programas ou parte. • A visão de implementação de um sistema abrange os componentes e os arquivos utilizados para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o gerenciamento da configuração das versões do sistema, compostas por componentes e arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para a produção de um sistema executável. Visão de Implementação Visão de Processo Introdução a UML Visão 4 + 1
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 29 • A visão do implantação de um sistema abrange os nós que formam a topologia de hardware em que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa visão são representados em diagrmas de implantação; os aspectos dinâmicos são capturados em diagramas de interações, de gráfico de estados e diagramas de atividades. Visão de Implantação Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes interessem. Essas cincos visões também interagem entre sí, por exemplo: Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez, representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões de projeto e de processo. Introdução a UML Visão 4 + 1
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 30 Desenvolvimento de Software Estrutura: Casos de Uso Seqüência (eventos) Colaboração Classes Distribuição Implementação Estrutura Comportamento interno Comportamento externo Análise de Requisitos Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 31 Produtos dos Workflows de Requisitos e de Análise: Documento de Visão Especificação de Requisitos (Casos de Uso) Vocabulário do Sistema Modelo Conceitual ou Modelo de Domínio Análise Requisitos Arquitetura Modelo de Arquitetura Inicial Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 32 Produtos dos Workflows de Projeto Projeto Diagrama de Seqüência / Colaboração Diagrama de Classes (Refinado) Diagrama de Atividades* Diagrama de Estados* * se necessário Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 33 Produtos dos Workflows de Arquitetura Arquitetura * se necessário Diagrama de Componentes Diagrama de Distribuição(Deployment) Modelo de Arquitetura Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 34 Por que fazer a modelagem? “A Modelagem captura as partes essenciais do sistema.” (Rumbaugh) Com a modelagem, alcançamos alguns objetivos: 1 - Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja 2 - Os modelos permitem especificar a estrutura ou o comportamento de um sistema 3 - Os modelos proporcionam um guia para a construção do sistema 4 - Os modelos documenta o sistema O Que é Modelagem Visual? Modelagem Visual significa modelar com a utilização de notações padrão. Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada. UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das mais populares do momento. Mas podemos optar por usar OMT, por exemplo. Construímos modelos para compreender melhor que estamos desenvolvendo Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 35 Modelagem visual significa modelar com a utilização de notações padrão. Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada. UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das mais populares do momento. A UML (Linguagem de Modelagem Unificado) é padrão mantido pelo OMG (www.omg.org/uml). O Que é Modelagem Visual? Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 36 O Quê é a UML? A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão para elaboração da estrutura de projetos de software. A UML poderá ser usada para: • Visualização • Especificação • Construção de modelos e diagramas • Documentação. A UML é adequada para a modelagem de sistemas, cuja a abrangência poderá incluir sistemas de informação corporativos a serem distribuídos a Aplicação baseadas em Web e até sistemas complexos embutidos de tempo real. A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para desenvolvimento de software. Ela é independente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura, iterativo e incremental. Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 37 ESTÁTICOS . Diagrama de Classes . Diagrama de Objetos . Diagrama de Componentes . Diagrama de Distribuição DINÂMICOS . Diagrama de Casos de Uso . Diagramas de Interação - Diagrama de Seqüência - Diagrama de Colaboração . Diagrama de Atividade . Diagrama de Estados Modela o comportamento do sistema Modela a estrutura do sistema Diagramas* Introdução a UML Nota: diagramas da versão 1.5
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 38 O Quê é a UML? A UML é linguagem para documentação A construção de software produz todos os tipos de artefatos além do código executável. Estes artefatos incluem o seguinte: - Requisitos - Arquitetura - Projeto - Código-Fonte - Planos de Projeto - Teste - Protótipos - Versões A UML abrange a documentação da arquitetura do sistema e de todos os seus detalhes. A UML também proporciona uma linguagem para expressão de requisitos e para realização de testes. Por fim, a UML oferece uma linguagem para modelagem das atividades de planejamento do projeto e de gerenciamento de versões. Onde a UML pode ser utilizada ? A UML se destina principalmente a construção de software complexos. Atualmente sendo empregada largamente na construção de Sites de E-commerce e E-business Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 39 O Quê é a UML? Blocos de construção da UML O Vocabulário da UML abrange três tipos de blocos de construção: - Itens - Relacionamentos - Diagramas - Itens, Existem quatro tipos de itens na UML Itens estruturais: São os substantivos utilizados em modelos da UML. São as partes mais estáticas do modelo, representando elementos conceituais ou físicos. Primeiro, as classes são descrições como conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamento e semântica. Nome Atributos Métodos Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 40 O Quê é a UML? Blocos de construção da UML - Itens (continuação), Segundo, uma interface é uma coleção de operações que especificam serviços de uma classe ou componente. Portanto, uma interface descreve o comportamento externamente visível desse elemento. Uma interface poderá representar todo o comportamento de uma classe ou componente, como também apenas parte do comportamento. A interface define um conjunto de especificações de operações (assinaturas), mas nunca um conjunto de implementações de operações. Calculo Terceiro, as colaborações definem interação e são sociedades de papéis e outros elementos que funcionam em conjunto para proporcionar um comportamento cooperativo superior à soma de todos os elementos. Portanto, as colaborações contêm dimensões estruturais, assim como comportamentais. As colaborações representam a implementação de padrões que formam um sistema . Cadeia de Responsabilidade Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 41 O Quê é a UML? Blocos de construção da UML - Itens (continuação), Quarto, um caso de uso é a descrição de conjunto de sequência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. Um caso de uso é utilizado para estruturar o comportamento de itens em um modelo. Um caso de uso é realizado por uma colaboração. Quinto, as classes ativas são classes cujos os objetos têm um mais processos ou threads e, portanto, podem iniciar a atividade de controle. Uma classe ativa é semelhante a um classe, exceto pelo fato de que seus objetos representam elementos cujo o comportamento é concorrente com o outros elementos. FazerPedido start() sleep() ControlEvent Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 42 O Quê é a UML? Blocos de construção da UML - Itens (continuação), Sexto, os componentes são partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces.Tipicamente os componentes representam, o pacote físico de elementos lógicos diferentes, como classes, interfaces e colaborações. Sétimo, um nó é elemento físico existente em tempo de execução que representa um recurso computacional, geralmente com pelo menos alguma memória e, frequentemente, capacidade de processamento. Exemplo de nós: - Computadores (estações clientes e servidores) - Redes - Roteadores Component.java Servidor Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 43 O Quê é a UML? Blocos de construção da UML - Itens Comportamentais São parte dinâmicas dos modelos de UML. São os verbos de um modelo, representado comportamento no tempo e espaço. Ao todo, existem dois tipos de itens comportamentais: Primeiro, um interação é um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos em determinado contexto para realização de propósitos específicos. As interações envolvem outros elementos, inclusive mensagens, sequência de ações (os comportamentos chamados pelas mensagens) e ligações (as conexões entre os objetos) Mostrar Segundo, uma máquina de estado é um comportamento que especifica as sequências de estados pelas quais objetos ou interações passam durante sua existência em resposta a eventos, bem como suas respostas a esses eventos. O comportamento de classe ou de uma colaboração pode ser especificado por meio de uma máquina de estados. Uma máquina de estados abrange mais elementos, tais como, transições (o fluxo de um estado a outro evento), evento (itens que disparam uma transição) e atividades (as respostas às transições). Aguardando Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 44 O Quê é a UML? Blocos de construção da UML - Itens de Agrupamentos Os itens de agrupamento são partes organizacionais dos modelos de UML. São os blocos em que os modelos podem ser decompostos. Ao todo, existe apenas um tipo principal de itens de agrupamento chamado de pacotes. Um pacote é mecanismo de propósito geral para a organização de elementos em grupos. Os itens estruturais, os itens comportamentais e até outros itens de grupos podem ser colocados em pacotes. Ao contrário dos componentes (que existem em tempo de execução), um pacote é puramente conceitual (o que significa que existe apenas em tempo de desenvolvimento. Aplicação Interface de Usuário Controle Regras de Negócios - Itens Anotacionais Itens anotacionais são as partes explicativas dos modelos UML. São comentários, incluídos para descrever, esclarecer e fazer alguma observação sobre qualquer elemento do modelo. Existe apenas um item anotacional chamado nota Imprimir Recibo Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 45 O Quê é a UML? Blocos de construção da UML - Relacionamentos Existem quatro tipos de relacionamentos na UML: 1 - Dependência 2 - Associação 3 - Generalização 4 - Realização Esses relacionamentos são blocos relacionais básicos de construção da UML. O primeiro dependência é um relacionamento semântico entre dois itens, nos quais a alteração de um (o item independente) pode afetar a semântica do outro (o dependente). Sua representa é linha tracejada, possivelmente com setas e ocasionalmente incluindo um rótulo. O segundo associação é um relacionamento estrutural que descreve um conjunto de ligações, em que as ligações são conexões entre objetos. A agregação é um tipo especial de associação, representando um relacionamento estrutural entre o todo e suas partes. É representada por uma linha sólida, possivelmente direcionadas, ocasionalmente incluído rótulos e freqüentemente, contendo outros adornos, como nomes de papéis e multiplicidade. Pessoa Empregador empregador 0..1 * funcionário Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 46 O Quê é a UML? Blocos de construção da UML O terceiro é a generalização é um relacionamento de especialização e generalização, nos quais os objetos dos elementos especializados (os filhos) são substituíveis por objetos do elemento generalizados (os pais). Dessa forma, os compartilham a estrutura e comportamento dos pais. Médico Clinico Geral Pediatra generalização especialização O quarto é a realização é um relacionamento semântico entre classificadores, em que um classificador especifica um contrato que outro classificador garante executar. Os relacionamentos de realização são encontrados em dois locais: entre interface e as classes ou componentes que as realizam; entre casos de uso e as colaborações que os realizam. Place order Order management colaboração Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 47 O Quê é a UML? Revisão Blocos de construção da UML O Vocabulário da UML abrange três tipos de blocos de construção: - Itens - Relacionamentos - Diagramas - Itens, Existem quatro tipos de itens na UML Itens estruturais: São os substantivos utilizados em modelos da UML. São as partes mais estáticas do modelo, representando elementos conceituais ou físicos. Primeiro, as classes são descrições como conjuntos de objetos que compartilham os mesmos atributos, operações, relacionamento e semântica. Segundo, uma interface é uma coleção de operações que especificam serviços de uma classe ou componente. Terceiro, as colaborações definem interação e são sociedades de papéis e outros elementos que funcionam em conjunto para proporcionar um comportamento cooperativo superior à soma de todos os elementos. Quarto, um caso de uso é a descrição de conjunto de sequência de ações realizadas pelo sistema que proporciona resultados observáveis de valor para um determinado ator. Quinto, as classes ativas são classes cujos os objetos têm um mais processos ou threads e, portanto, podem iniciar a atividade de controle Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 48 O Quê é a UML? Revisão Sexto, os componentes são partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces. Sétimo, um nó é elemento físico existente em tempo de execução que representa um recurso computacional - Itens Comportamentais São parte dinâmicas dos modelos de UML. São os verbos de um modelo, representado comportamento no tempo e espaço. Ao todo, existem dois tipos de itens comportamentais: Primeiro, interação é um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos em determinado contexto para realização de propósitos específicos. Segundo, uma máquina de estado é um comportamento que especifica as sequências de estados pelas quais objetos ou interações passam durante sua existência em resposta a eventos, bem como suas respostas a esses eventos. Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 49 Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 50 Casos de Uso O que são Caso de Uso? São diagramas de que permitem visualizar, especificar e documentar o comportamento de um elemento. Esses diagramas fazem com que sistema, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos podem ser utilizados no contexto. Definição: Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive variantes, que um sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma elipse. Elementos dos Caso de Uso: Ator: Um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham quanto interagem com esses casos de uso. Geralmente um ator representa um papel, que pode ser de pessoa, de um sistema ou de um dispositivo. Cenários: Podemos definir os cenários como uma instância de um Caso de uso. O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos cenários quantos forem necessários para se entender completamente todo o sistema. Podem ser considerados como teste informais para validação dos requisitos do sistema. Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 51 Diagramas de Caso de Uso e Extensões Professor Selecionar curso para ensinar Pedir lista dos matriculados Gerente Manter informação de aluno Manter informação de professor Gerar catalogo Manter informações dos cursos Sistema de cobrança Matrícula nos Cursos Aluno Casos de Uso Generalização: Entre casos de uso é parecida à generalização existente entre as classes. No caso de uso a generalização significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça. Include: Quando você estiver se repetindo em dois ou mais caso de uso separados devemos evitar a repetição Extends: Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso. Realizes: Especifica a colaboração entre os casos de uso Use (obsoleto): Especifica que a semântica do elemento de origem depende da semântica da parte pública do destino Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 52 Descrição dos Cenários: Nome AutenticarSenha Descrição Autenticar Senha Objetivo Identificar o usuário, autenticar senhas e autorizar acesso. Atores Usuário Papéis: Funcionário Administrativos, Alunos e Professores Pré Condição Usuário cadastro no sistema senhas, Usuário não estar “logado” Dados Entrada e Saída Entrada: Código do usuário e senha de acesso Saída: Autorização para uso (Pasta de Acesso) ou uma mensagem de alerta Sequência de troca mensagens Ator Sistemas 1. Usuário chama uma interface Registro 2. Usuário informa seu código e sua senha. 3. Usuário requisita autenticação dos dados informados. 8 Usuário recebe a mensagem, ou seja, a autorização Pasta de Acesso, formatada de acordo sua interface. 4. Aplicativo processa a autenticação da senha, faz a identificação do usuário. Verificar se usuário tem o status de Liberado. 5. Conferir se senha não está expirada. 6. Conferir se senha informada coincide com a senha gravada. 7. Retornar uma mensagem e uma assinatura. Curso Alternativo (Exceção): Ator Sistemas 4. Usuário com status de bloqueado. Retornar mensagem de alerta/erro 5. Senha expirada. Retornar mensagem de alerta/erro (O usuário deverá trocar a senha – ver case de uso AlterarSenha) 6. Senha não confere. Retornar mensagem de alerta/erro de senha inválida. Registrar a quantidade de tentativas sem sucesso, caso seja igual a 5 (limite de tentativas) o sistema bloqueará o usuário, mudando o status de liberado para bloqueado automaticamente. Pós Condição Autorização (Pasta de acesso) Interfaces Registro Casos de Uso Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 53 Descrição dos Cenários: Regras de Negócios Casos de Uso Regras de Negócios: Autenticação: A senha será validada, seguindo as regras de negócios de Autenticação de Senha: 1 - O usuário deve estar cadastrado no Aplicativo; 2 - A senha não pode estar expirada; 3 - O usuário deve ter um “status” de Liberado; 4 - A senha informada (criptografada) deve coincidir com senha gravada na tabela de senhas. Autorização 5 - Somente o usuário detentor da senha poderá altera-lá Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 54 Ator Casos de Uso - Identicação de Atores Os atores não são parte do sistema - eles representam qualquer um e qualquer coisa que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc. Uma ator pode: - Apenas fornecer informações ao sistema - Apenas receber informações ao sistema - Fornecer e receber informações ao sistema Tipicamente os atores são identificados nas declarações de problemas ou através de entrevistas com os usuários e outros analistas envolvidos no processo, como, Analista de Sistema e Analista de Negócio, por exemplo. As seguintes questões podem ser usadas para identificar o atores: - Onde o sistema será usado ? - Quais áreas serão usuárias do sistema ? - O sistema usará recurso externo ? - Quem será o responsável pelo sistema ? - Quem serão os usuários do sistema ? Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 55 Casos de Uso Generalização: Entre casos de uso é parecida à generalização existente entre as classes. No caso de uso a generalização significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça. Include: Quando você estiver se repetindo em dois ou mais caso de uso separados, devemos evitar a repetição Extends: Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso. Realizes: Especifica a colaboração entre os casos de uso Use (obsoleto): Especifica que a semântica do elemento de origem depende da semântica da parte pública do destino Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 56 Explicando o estereotipo <<extend>> Extend: Podemos usa-los em dois momentos 1 Variação Cada uma das extensões descreve as diferentes maneiras com que um passo do caso de uso pode ser executado. Exemplo: Casos de Uso Dinheiro ReceberConta CartaoCredito Cheque <<extend>><<extend>> <<extend>> 2 Casos excepcionais Condições de falha que podem ocorrer e serem recuperada em único passo e requerem um caso de uso para sua descrição. AlterarDisponibilidadeCarro ConsultarCliente <<include>> DevolvendoCarro CalcularMulta <<extend>> <<include>> Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 57 Casos de Uso PlaceOrder <<include>> Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma localização especificada na base. O caso de uso incluído nunca permanece isolado, mas é apenas uma “instance” como parte de alguma base maior que o inclui. Você pode pensar na inclusão como o caso de uso base que o obtém o comportamento a partir do fornecedor do caso de uso. Você utiliza um relacionamento de inclusão para evitar descrever o mesmo fluxo de eventos várias vezes, incluindo o comportamento comum em um caso de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois, permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de responsabilidade sempre que precisamos utilizar essa funcionalidade. Explicando o estereotipo <<include>> TrackOrder ValidateUser<<include>> Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 58 Locadora de carros Uma locadora aluga carros aos clientes previamente cadastrados. Caso o cliente não esteja cadastrado, esta atividade custodial é realizada, separadamente em outra atividade do sistema. Caso um carro, disponível, seja escolhido pelo cliente este é alugado, sendo registrada a data inicial junto ao aluguel. Para que o cliente possa alugar um carro, este não pode estar com dívida pendente. Os carros são descritos pela placa, ano, modelo, descrição, km, preço por km, situação(disponível, etc), taxa diária, observações(informações gerais) e sua imagem. Os clientes são cadastrados pelo seu cpf, nome, endereço, telefone e dívida(reservado para registrar pagamentos pendentes). Quando o cliente devolve o carro, a situação do carro é mudada para “disponível”, o km é atualizado com o km atual do carro e um recibo é emitido, baseado nos kms rodados e nos dias em que ficou com o carro. Ainda na atividade de devolução é removido o registro do aluguel e, caso o cliente não possa pagar, a dívida do aluguel é registrada junto ao cliente. Exemplo: Casos de Uso Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 59 Objetivo: Fazer locação de carros Restrição: Cliente não pode ter dividas pendentes Atores: Atendente Entidade Custodial Candidatos a Casos de Usos: Cadastrar Cliente Cadastrar Carro VerificarDadosCliente VerificarDividadoCliente VerificarDisponibilidadeVeiculo (Locar) EntregarVeiculo (Devolução) ReceberVeículo EmitirRecibo RegistrarDivida Candidatos a Classe: Veículos Clientes Divida do Cliente Locação Empregado Exemplo: Casos de Uso Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 60 Continuação: Atores: Atendente: Faz o atendimento ao cliente da Locadora Entidade Custodial: Faz o cadastro da custódia do cliente Candidatos a Casos de Usos: Cadastrar (Cliente e Carro) VerificarDadosCliente (Se é cliente e se tem divida) VerificarDisponibilidadeVeiculo EntregarVeiculo ReceberVeículo EmitirRecibo RegistrarDivida Candidatos a Classe: Veículo DadosdoCliente DividadoCliente Locação Empregado Exemplo: Casos de Uso Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 61 Diagrama de Caso de Uso EntregarVeiculo Verif icarDisponibilidadeVeiculo <<include>> Verif icarDadosCliente <<include>> SocilicarCadastro EntidadeCustodia <<extend>> AlterarDisponibidadeVeiculo ReceberVeiculo <<include>> ImprimirReciboRegistrarDiv ida ReceberPagtoCliente <<include>> <<extend>> <<extend>> Atendente Cadastrar CadastrarCliente CadastrarCarro Exemplo: Casos de Uso Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 62 Cenário do Caso de Uso: VerificarDadosCliente Casos de Uso Nome: VerificarDadosCliente Objetivo: Verificar se Cliente está cadastro no Sistema e e divida pendente Pré-condição: Cliente solicitar uma locação Ator: Atendente Fluxo Normal: 1-O atendente solicita o número do CPF 2-Digita o CPF no sistema 3-O sistema verifica se cliente está cadastrado e se tem divida pendente 4-O sistema envia mensagem cliente cadastrado e não há divida Fluxo Alternativo 1 (Cliente não cadastrado): 4-O sistema envia mensagem cliente não cadastrado 5-Solicita o cadastro da custódia do cliente Fluxo Alternativo 2 (Cliente com divida): 4-O sistema envia mensagem cliente cadastrado e com divida pendente Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 63 Diagrama de Seqüência O que é Diagramas de Seqüência? É um diagrama que exibe a colaboração dinâmica entre os vários objetos de um sistema. O principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos, alguma evento que acontecerá em um ponto específico da execução do sistema. formulários de registro formulário de matrícula cursos disponíveis Ator (José) entrar com chave de acesso validar acesso entrar com o semestre criar nova matrícula apresentar em tela obter cursos Diagrama de Seqüência Introdução a UML Explicando o diagrama: O diagrama de seqüência consiste em um número de objetos mostrado em linhas verticais. O decorrer do tempo é visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto são simbolizadas por setas entre os objetos que se relacionam. Diagramas de seqüência possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos na seqüência de uma certa atividade. Eles também mostram as interações para um cenário específico de uma certa atividade do sistema.
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 64 Diagrama de Seqüência Diagramas da UML Diagrama de Seqüência Explicando o diagrama (continuação) No eixo horizontal estão os objetos envolvidos na seqüência. Cada um é representado por um retângulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamada de linha de vida do objeto, indicando a execução do objeto durante a seqüência, como exemplo citamos: mensagens recebidas ou enviadas e ativação de objetos. A comunicação entre os objetos é representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos. A seta especifica se a mensagem é síncrona, assíncrona ou simples. As mensagens podem possuir também números seqüenciais, eles são utilizados para tornar mais explícito as seqüência no diagrama. Em alguns sistemas, objetos executam de forma concorrente, cada um com sua linha de execução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado como ativação, mensagens assíncronas, ou objetos assíncronos. Os diagramas de seqüência podem mostrar objetos que são criados ou destruídos como parte do cenário documentado pelo diagrama. Um objeto pode criar outros objetos através de mensagens. A mensagem que cria ou destrói um objeto é geralmente síncrona, representada por uma seta sólida
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 65 Diagrama de Seqüência Exemplo: EntregarVeiculo : Atendente : Cliente : Veiculo : Locacao getDadosCliente( ) [* se cliente cadastrado verificar divida ] getDivida( ) getDisponibilidade( ) [* se veículo disponível ] setSaida( ) Este diagrama descreve em ordem cronológica as mensagens entre os objetos. Neste momento estamos dizendo o como o Caso de Uso deve ser implementado Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 66 Diagrama de Seqüência Explicando os detalhes: : Atendente : Cliente : Veiculo : Locacao getDadosCliente( ) [* se cliente cadastrado verificar divida ] getDivida( ) getDisponibilidade( ) [* se veículo disponível ] setSaida( ) ator Instance das classes Linha do tempo As interações entre os objetos Restrição ou condição Autodelegação Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 67 Diagrama de Colaboração O que é Diagramas de Colaboração? É um diagramas que mostra a colaboração dinâmica entre os objetos, semelhante ao diagrama de seqüência. No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos, percebe-se também os objetos com os seus relacionamentos. A interação de mensagens é mostrada em ambos os diagramas. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de seqüência, mas se a ênfase for o contexto do sistema, é melhor dar prioridade ao diagrama de colaboração. Podemos também escolher ambos. O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens são nomeadas, que entre outras coisas mostram a ordem em que as mensagens são enviadas. Também podem mostrar condições, interações, valores de resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que executam paralelamente com outros. 6:obter cursos Ator (José) formulários de registro 2: validar acesso 1:entrar com chave de acesso 3:entrar com o semestre 4:criar nova matrícula formulário de matrículacursos disponíveis 5:apresentar em tela Diagrama de Colaboração Diagramas da UML NOTA: O diagrama de colaboração em alguns caso pode ser considerado opcional. Pode-se escolher entre utilizar o diagrama de colaboração ou o diagrama de seqüência.
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 68 Diagrama de Colaboração : Atendente : Cliente : Veiculo : Locacao 1: getDadosCliente( ) 2: getDivida( ) 3: getDisponibilidade( ) 4: setSaida( ) Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 69 Diagrama de Estado O que é Diagrama de Estado? É um diagrama que tipicamente complementa a descrição das classes. Pois este diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se encontrar e mostra também quais são os eventos do sistemas que provocam tais mudanças. Não necessário escrever o diagrama de estado para todas as classes de um sistema, mas apenas para aquelas que possuem um número definido de estados conhecidos e onde o comportamento das classes é afetado e modificado pelos diferentes estados. Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens recebidas, tempo, erros, e condições sendo satisfeitas) afetam estes estados ao passar do tempo. Registro fechado [númeroDeAlunos<3] cancelarCurso cancelarCurso cancelarCurso Registro fechado [númeroDeAlunos>=3 ] Registro fechado [número de alunos =10]^Curso .Criar relatório Matrícula aberta/inicialize númeroDeAlunos = 0 Curso Completado faça: Gerar lista de alunos Criação faça: Crie o objeto curso Atribuição Curso faça: Atribuir um professor ao curso Curso Aberto Entrada: Registre um aluno Adicionar Aluno Curso Encerrado faça: relate curso esta cheio Curso Cancelado faça: envie notificação de cancelamento cancelarCurso Projeto e Modelagem Visual com UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 70 Diagrama de Estado Projeto e Modelagem Visual com UML Diagramas de estado possuem um ponto de início e vários pontos de finalização. Um ponto de início (estado inicial) é mostrado como um círculo todo preenchido, e um ponto de finalização (estado final) é mostrado como um círculo em volta de um outro círculo menor preenchido. Um estado é mostrado como um retângulo com cantos arredondados. Entre os estados estão as transições, mostrados como uma linha com uma seta no final de um dos estados. A transição pode ser nomeada com o seu evento causador. Quando o evento acontece, a transição de um estado para outro é executada ou disparada. Uma transição de estado normalmente possui um evento ligado a ela. Se um evento é anexado a uma transição, esta será executada quando o evento ocorrer. Se uma transição não possuir um evento ligado a ela, a mesma ocorrerá quando a ação interna do código do estado for executada (se existir ações internas como entrar, sair, fazer ou outras ações definidas pelo desenvolvedor). Então quando todas as ações forem executadas pelo estado, a transição será disparada e serão iniciadas as atividades do próximo estado no diagrama de estados. Verificando Estado Transição Fim Inicio Elementos
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 71 Diagrama de Estado Projeto e Modelagem Visual com UML Exemplo: Diagrama de Estado Telefone ocioso início Ativo fora do gancho no gancho transição Estado Os diagramas de estados são compostos de transições e estados. As transições são associadas com ações e são consideradas como processo de curta duração e não podem ser interrompidos. Os estados são associados com as atividades e podem levar mais tempo. Uma atividade pode ser interrompida por algum evento. Final
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 72 Diagrama de Estado Projeto e Modelagem Visual com UML Aplicação Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como: - Classes - Tipos (conceitos) - Casos de Uso Exemplo: início Verificando Expedindo Aguardando Cancelamento cancelamento Entregue cancelado [Todos os itens verificados e alguns itens não estão disponíveis] [Todos os itens verificados e os todos itens disponíveis] Item recebido [os todos itens disponíveis] final [Nem todos os itens verificados]/pegar próximo item [itens ecebidos [alguns itens não estão disponíveis]
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 73 Diagrama de Atividade O que é Diagrama de Atividade? É um diagramas que exibe o fluxo seqüencial das atividades, é geralmente utilizado para demonstrar as atividades executadas por uma operação específica do sistema, como por exemplo seleção de um item do menu principal. Consistem em estados de ação, que contém a especificação de uma atividade a ser desempenhada por uma operação do sistema. Decisões e condições, como execução paralela, também podem ser mostrados na diagrama de atividade. O diagrama também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas. Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho executado na implementação de uma operação (método), e suas atividades numa instância de um objeto. O diagrama de atividade é uma variação do diagrama de estado e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar ações (trabalho e atividades que serão executados) e seus resultados em termos das mudanças de estados dos objetos. Projeto e Modelagem Visual com UML Fazer Pedido Cliente Processar Pedido Separar Produtos Enviar Pedido Cobrar Cliente Fechar Pedido Receber Pedido Pagar Fatura Vendas Estoque
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 74 Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é executada (sem ser necessário especificar nenhum evento como no diagrama de estado). Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como swimlanes (raias). Uma swimlane agrupa atividades, com respeito a quem é responsável e onde estas atividades residem na organização, e é representada por retângulos que englobam todos os objetos que estão ligados a ela (swimlane). Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com a possibilidade de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos), quando elas são executadas (seqüência das ações), e onde elas acontecem (swimlanes). Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:  Para capturar os trabalhos que serão executados quando uma operação é disparada (ações). Este é o uso mais comum para o diagrama de atividade.  Para capturar o trabalho interno em um objeto.  Para mostrar como um grupo de ações relacionadas podem ser executadas, e como elas vão afetar os objetos em torno delas.  Para mostrar como uma “instance” pode ser executada em termos de ações e objetos.  Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no negócio). Enfim o diagrama de atividade mostra o fluxo seqüencial das atividades, é normalmente utilizado para demonstrar as atividades executadas por uma operação específica do sistema. Consistem em estados de ação, que contém a especificação de uma atividade a ser desempenhada por uma operação do sistema. Decisões e condições, como execução paralela, também podem ser mostrados na diagrama de atividade. O diagrama também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas. Projeto e Modelagem Visual com UML Diagrama de Atividade
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 75 Exemplo: Diagrama de Atividades Projeto e Modelagem Visual com UML Diagrama de Atividade
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 76 Diagrama de Atividade Componentes: Projeto e Modelagem Visual com UML Fazer Pedido Cliente Processar Pedido Separar Produtos Enviar Pedido Cobrar Cliente Fechar Pedido Receber Pedido Pagar Fatura Vendas Estoque raias junção separação atividade Atividade atividade transição decisão Barras de sincronização Exemplo com comentários:
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 77 Diagrama de Atividade Projeto e Modelagem Visual com UML Exemplo com comentários: Receber Pedido Preencher Pedido Receber Pagamento Enviar Fatura Entrega durante a noite Entrega Regular [pedido urgente] [senão] Encerrar Pedido Entrega
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 78 Diagrama de Pacotes Como podemos definir o diagrama de pacotes? A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é linha pontilhada com uma seta que indica dependência. A notação usada pela UML para representar pacotes é: Nome do Pacote Exemplo: As classes pertencentes ao Sistema de Matrícula podem ser agrupadas em três pacotes: • UI (Interface Usuário) • Regras de Negócio • Interfaces de Banco de Dados Interfaces de Banco de Dados {abstrata} Interfaces com Usuário Regras de Negócios Interface MySQL Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 79 Podemos usar a estrutura de pacotes para criar coesão entre as classes que tem objetivo comum, por exemplo podemos colocar em único pacote todas as classes que se referem a regras de negócios. Exemplo: Fisicamente os pacotes tem a estrutura de diretório e subdiretório, isto que dizer que a Aplicação terá a seguinte formato: Aplicação Regras de Negócios Interface de Usuário Controle Aplicação Interface de Usuário Controle Regras de Negócios Diagrama de Pacotes Projeto e Modelagem Visual com UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 80 Diagrama de Classes O que é um Diagrama de Classes? É um diagrama que demonstra a estrutura estática das classes de um sistema e seus relacionamentos. Classes podem se relacionar com outras através de diversas maneiras: associação (conectadas entre si), dependência (uma classe depende ou usa outra classe), especialização (uma classe é uma especialização de outra classe), ou em pacotes (classes agrupadas por características similares). Todos estes relacionamentos são mostrados no diagrama de classes juntamente com as suas estruturas internas, que são os atributos e operações. O diagrama de classes é considerado estático já que a estrutura descrita é sempre válida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, já que não são todas as classes que estão inseridas em um único diagrama e uma certa classes pode participar de vários diagramas de classes. 1..* 1 1 tem Professores Pessoa Alunos Funcionários Administrativo Curso Disciplinas Matricula 11 1 Uma classe num diagrama pode ser diretamente implementada utilizando-se uma linguagem de programação orientada a objetos que tenha suporte direto para construção de classes. Para criar um diagrama de classes, as classes têm que estar identificadas, descritas e relacionadas entre si. Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 81 Diagrama de Objetos O que é um Diagrama de Objetos? É um diagrama que exibe uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama de objetos mostra os objetos que foram “instanciados” das classes. O diagrama de objetos é como se fosse o perfil do sistema em um determinado momento de sua execução. A mesma notação do diagrama de classes é utilizada, entretanto há duas diferenças: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de objetos não tem a mesma importância do diagramas de classes, mas eles são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão. Diagramas de objetos também são usados como parte dos diagramas de colaboração, onde a colaboração dinâmica entre os objetos do sistema são mostrados. Nome: “Fulano de Tal” Data: 23-02-2001 :Aluno Matricula: 201-23-02-01 Curso: Adm Empresas 201-23-02-01:Matricula Introdução a UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 82 Diagrama de Classes Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 83 Mapeamento do Diagrama de Classes e Modelo de Entidades e Relacionamento MER Entidades Relacionamentos Atributos Roles Constraints Generalização e Especialização UML Classes Persistentes Associação Atributos Roles Multiplicidade Generalização e Especialização Veja a tabela abaixo que relaciona as característica da UML e MER: Pessoa -idpessoa -nome Pessoa Idpessoa <pk> nome Classe persistente Entidade Os atributo de uma classe persistente são mapeado para colunas de entidade Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 84 Mapeamento Diagrama de Classes e Modelo de Entidades e Relacionamento Um exemplo de mapeamento Diagrama de classe (UML) e entidade (MER) Pessoa -nome -idade Funcionário funcao {abstract} Cliente Idcliente telefone Classes Veja agora o mapeamento para entidade MER, para cada classe criaremos uma entidade correspondente: Pessoa idpessoa <pk> nome idade Funcionário Cliente é um idpessoa <fk> funcao idpessoa <fk> idcliente <pk> telefone é um Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 85 Mapeamento Diagrama de Classes e Modelo de Entidades e Relacionamento Neste exemplo o mapeamento é feito para duas entidades: Funcionário idfunc <pk> nome idade funcao Cliente idcliente <pk> nome idade telefone Diagramas da UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 86 Diagrama de Componente O que é um Diagrama de Componente? É um diagrama que exibe o sistema por um lado funcional, expondo as relações entre seus componentes e a organização de seus módulos durante sua execução. O diagrama de componente descreve os componentes de software e suas dependências entre si, representando a estrutura do código gerado. Os componentes são a implementação na arquitetura física dos conceitos e da funcionalidade definidos na arquitetura lógica (classes, objetos e seus relacionamentos). Eles são tipicamente os arquivos implementados no ambiente de desenvolvimento. Curso.jar Pessoa.jar Aluno.class Professores.classDisciplina.classr Introdução a UML Um componente é mostrado em UML como um retângulo com uma elipse e dois retângulos menores do seu lado esquerdo. O nome do componente é escrito abaixo ou dentro de seu símbolo. Componentes são tipos, mas apenas componentes executáveis podem ter instâncias. Um diagrama de componente mostra apenas componentes como tipos. Para mostrar instâncias de componentes, deve ser usado um diagrama de execução, onde as instâncias executáveis são alocadas em nodes.
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 87 Diagrama de Componente Introdução a UML A dependência entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para possuir uma definição completa. Com o diagrama de componentes é facilmente visível detectar que arquivos .jar são necessários para executar a aplicação. Componentes podem definir interfaces que são visíveis para outros componentes. As interfaces podem ser tanto definidas ao nível de codificação (como em Java) quanto em interfaces binárias usadas em run-time (COM). Uma interface é mostrada como uma linha partindo do componente e com um círculo na outra extremidade. O nome é colocado junto do círculo no final da linha. Dependências entre componentes podem então apontar para a interface do componente que está sendo usada. Reserva.jar Pessoa.jar PessoaFisica. PessoaJuridicaCheckIN Exemplo:
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 88 Diagrama de Distribuição O que é Diagrama de Distribuição? É um diagrama que exibe a arquitetura física do hardware e do software no sistema. Pode apresentar os atuais computadores e periféricos, juntamente com as conexões que eles estabelecem entre si e pode mostrar também os tipos de conexões entre esses computadores. Especifica-se também os componentes executáveis e objetos que são alocados para mostrar quais unidades de software são executados e em que destes computadores são executados. O diagrama de distribuição demonstra a arquitetura runtime de processadores, dispositivos físicos e de software que executam no ambiente onde o sistema desenvolvido será utilizado. É o último diagrama da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade. O diagrama de distribuição é composto por componentes, que possuem a mesma simbologia dos componentes do diagrama de componentes, nodes, que significam objetos físicos que fazem parte do sistema, podendo ser uma computador cliente em uma Rede, um computador Servidor, uma impressora, um roteador, etc., e conexões entre estes nodes e componentes que juntos compõem toda a arquitetura física do sistema. Cliente A Servidor de Aplicação Servidor de Banco de Dados <<TCP/IP>> <<TCP/IP>> 0..* 1 1 1 Projeto e Modelagem Visual com UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 89 Diagrama de Distribuição Exemplo: Projeto e Modelagem Visual com UML Cliente Servidor Firewall Banco de Dados Web Oracle Server Apache sob Linux HTPP HTPP * 1 Banco de Dados Corporativo MySQL
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 90 Projeto de Desenvolvimento: Um exemplo
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 91 Exemplo de Projeto de Desenvolvimento com UML Projeto de Desenvolvimento Fases do Desenvolvimento O desenvolvimento de um sistema de informação, de acordo com metodologia rápida, é divido em duas etapas: enquanto a primeira fase, Definição de Requisitos, tem por objetivo determinar os requisitos, a segunda Análise, tem a finalidade de definir os módulos componentes do sistema. Definição dos Requisitos O objetivo desta fase é determinar a funcionalidade esperada pelo usuário do sistema. Num projeto de construção civil, esta fase corresponderia ao projeto de arquitetura, onde se descrevem as características da casa que são visíveis ao seu morador. O produto desta fase é chamado de Modelo de Requisitos. A estrutura do Modelo de Requisitos é exibida na figura abaixo. Cada uma das caixas representa um ou mais documentos que devem ser apresentados no final da fase. O diagrama indica que o modelo de Requisitos é composto de: Modelo de Casos de Uso, uma protótipo e um Glossário. Por sua vez, o Modelo de Casos de uso é composto de diagramas de caso de uso, cada destes contém uma descrição para o caso de uso. Modelos de Requisitos Diagrama de Casos de Uso Protótipo Glossário Casos de Uso Descrição do Caso de Uso 1..* 1..*
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 92 Segunda fase: Análise e Projeto O objetivo desta fase é produzir um plano que permita a construção do sistema. Por exemplo, comparando mais uma vez a engenharia civil, esta fase corresponderia às plantas detalhadas da construção de uma casa. Em termos de software, a planta do sistema é a especificação de suas classes componentes, que chamamos de Modelo de Análise e Projeto. O Modelo de Análise e Projeto é composto pelo Modelo Estático e pelo Modelo Dinâmico. O modelo estático é composto por um conjunto de diagramas de classes. O Modelo Dinâmico é composto por conjuntos de Diagramas de Seqüência e Diagrama de Estados. Modelos de Análise e Projeto Modelo Estático Modelo Dinâmico Diagrama de Classes Classes Diagrama de Sequência Diagrama de Estado 1..* 1..* 1..* 1..* Projeto de Desenvolvimento Exemplo de Projeto de Desenvolvimento com UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 93 Roteiro para o Desenvolvimento de Sistema usando a Metodologia Rápida 1 - Definir o escopo do Sistema; 2 - Produzir o Modelo de Requisitos 2.1 - Identificar os casos de usos 2.2 - Identificar os atores 2.3 - Identificar e definir as entidades do domínio do problema 2.4 - Definir os casos de uso que podem ser abstraídos 2.5 - Fazer agrupamento dos casos de uso com semântica semelhante 2.6 - Verificar o Modelo de Requisitos 3 - Produzir o Modelo de Análise e Projeto, executando as seguintes etapas: 3.1 - Criar um diagrama com modelo de classes do domínio do problema; 3.2 - Criar um diagrama com o modelo de classes de cada agrupamento de casos de uso. Este modelo deve conter as classes de domínio, interface e controle envolvidas no agrupamento de casos de uso. 3.3 - Fazer um diagrama de seqüência para cada agrupamento de caso de uso. 3.4 - Criar um diagrama de transição e estados para as classes de domínio, interface e controle que tenham ciclos de vida não-triviais. 3.5 - Revisar o diagrama de classes (reveja os relacionamentos) 3.6 - Verificar o modelo de Análise e Projeto. Projeto de Desenvolvimento Exemplo de Projeto de Desenvolvimento com UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 94 Estudo de Caso e Exercício
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 95 Estudo de Caso Caso Prático • A Universidade ESU quer informatizar seu sistema de matrícula – A Secretaria produz o currículo para o semestre – Os Alunos selecionam 4 matérias principais e 2 matérias alternativas – Após a matrícula, o sistema de cobranças será notificado para que receba o pagamento do estudante por um semestre – Os Alunos podem usar o sistema para adicionar ou remover matérias por um determinado período após a matrícula – Os Professores usam o sistema para receber a lista de ofertas de cursos – Os usuários do sistema de matrícula tem senhas que são utilizadas para validação de logon
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 96 Atores • Um Ator é alguém ou alguma coisa que deve interagir com o sistema a ser desenvolvido Aluno Secretaria Professor Sistema Cobrança Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 97 Casos de Uso: • Um caso de uso é um padrão de comportamento que o sistema exibe – Cada caso de uso é uma seqüência de transações relacionadas executadas por um ator e o sistema num diálogo • Atores são examinados para determinar suas necessidades – Secretaria -- manter o curriculum – Professor -- solicitar lista de cursos – Aluno -- manter o horário de aulas – Sistema Cobrança -- recebe informações sobre cobranças Manter Horário Manter Curriculum Solicitar Lista de Cursos Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 98 Documentando Caso de Uso • Um documento de fluxo de eventos é criado para cada caso de uso – Escrito do ponto de vista do ator • Detalha o que o sistema deve fornecer quando o caso de uso é executado • Conteúdos típicos – Como o caso de uso inicia e termina – Fluxo normal de eventos – Fluxos alternativos de eventos – Fluxos excepcionais de eventos (respostas a erros) Fluxo de Eventos de Manter Curriculum • Este caso de uso inicia quando a Secretaria entra no sistema e entra sua senha. O sistema verifica se a senha é válida (E-1) e solicita a escolha do semestre atual ou futuro (E-2). A Secretaria entra o semestre desejado. O sistema pergunta qual a atividade desejada: INCLUIR, APAGAR, MODIFICAR, ou SAIR. • Caso a atividade selecionada seja INCLUIR, o S-1: O sub-fluxo Inclui uma Matéria é executado. • Caso a atividade selecionada seja APAGAR, o S-2: O sub-fluxo Apaga uma Matéria é executado. • Caso a atividade selecionada seja MODIFICAR, o S-3: O sub-fluxo Modificar uma Matéria é executado. • Caso a atividade selecionada seja SAIR, o caso de uso termina. • ... Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 99 Diagrama de Caso de Uso • Diagramas de caso de uso são criados para se visualizar a relação entre atores e casos de uso Aluno Secretaria Professor Mantém Horário Mantém Curriculum Solicita Lista de Cursos Sistema Cobrança Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 100 Usos e Extensões das Relações de Casos de Uso • À medida em que casos de uso são documentados, outras relações entre casos de uso poderão ser descobertas – Uma relação de uso (usa) mostra comportamento que é comum a um ou mais casos de uso – Uma relação de extensão mostra comportamento opcional Matricular para cursos <<extends>> Validar Senha <<extends>> Manter Curriculum Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 101 Realizações de Casos de Uso: • O Diagrama de Caso de Uso apresenta uma visão externa do sistema • Diagramas de Interação descrevem como casos de uso são realizados como interações entre associações de objetos • Há dois tipos de Diagramas de Interação – Diagramas de Seqüência – Diagramas de Colaboração Diagrama de Seqüência: • Um Diagrama de Seqüência mostra interações de objetos ordenados numa seqüência de tempo : Aluno 1: preenche 2: envia 3: curso(Maria,matemática) 4: está aberto? 5: está aberto? 6: incui(Maria l) 7: incui (Maria) Formulário de Matrúcula Gerente de Matrículas Matemática Básica Matemática Álgebra Tempo Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 102 • Um Diagrama de Colaboração mostra interações organizadas à volta de objetos e as ligações de um para o outro Diagrama de Colaboração : Secretaria curso form : cursoForm Diretor : Diretor_do_Curso acurso : curso 1: pega informação curso 2: processa 3: incui curso 4: novo curso Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 103 Diagrama de Classes • Um Diagrama de Classes mostra a existência de classes e suas relações com a visão lógica do sistema • Elementos de UML presentes nos Diagramas de Classes: – Classes, suas estruturas internas e comportamento – Associações, agregações, dependências, e relações de herança – Multiplicidade e indicadores de navegação – Nomes de papéis (O que uma classe representa para outra) Classes • Uma classe é uma coleção de objetos com um estrutura, comportamento, relações e semântica comuns • Classes são descobertas pelo exame dos objetos nos diagramas de Seqüência e Colaboração • Uma classe é desenhada como um retângulo com três compartimentos: – Primeiro: Nome da classe – Segundo: Atributos (opcional) – Terceiro: Métodos (opcional) • Classes devem ser nomeadas usando o vocabulário do domínio – Padrões de nomenclatura devem ser estabelecidos – Regra: Todos os nomes de classes são substantivos no singular, iniciando com letra maiúscula Exemplo: Cliente, Fornecedor, Pessoa, Aluno e etc. Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 104 Diretor Matrícula Formulário Matrícula Professor Aluno Oferta Curso Curso Algorítmo de Horário Classes: Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 105 • O comportamento de uma classe é representado pelas suas operações • Operações podem ser encontradas examinando-se os Diagramas de Interação Matrícula form Matrícula Gerente 3: matricula curso(Maria, matemática) Diretor Matrícula Matricula (aluno,curso) Classes: Atributos: Cada Curso oferecido possui um número, local e horário Oferta Curso número local horário Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 106 Classes curso nome NúmeroCréditos abrir() incluirAluno(AlunoInfo) Aluno nome nível Professor nome StatusCadeira Algorítmo de Horário Formulário Matrícula Diretor Matrícula incluiAluno(curso, AlunoInfo) Oferta Curso local abrir() incluirAluno(AlunoInfo) Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 107 Relacionamento: • Relações fornecem um caminho para a comunicação entre os objetos • Diagramas de seqüência e/ou colaboração são examinados para determinar quais ligações entre objetos precisam existir para se chegar ao comportamento desejado. -- Caso dois objetos precisem “conversar” deverá haver uma ligação entre elas • Há três tipos de relações: – Associação e Agregação – Dependência – Herança • Uma associação é uma conexão bidirecional entre classes – Uma associação é mostrada como uma linha conectando as classes relacionadas. • Uma agregação é um tipo mais forte de conexão, aonde a relação é entre o todo e suas partes. – Uma agregação é mostrada como uma linha conectando as classes relacionadas com um losango perto da classes que representa o todo • Uma relação de dependência é uma forma mais fraca de relação, mostrando uma relação entre um cliente e um fornecedor, aonde o cliente não tem conhecimento semântico do fornecedor – Uma dependência é mostrada como uma linha pontilhada entre o cliente e o fornecedor Associação: Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 108 Descobrindo os Relacionamentos: • Relações são descobertas examinando-se os Diagramas de Sequência – Caso dois objetos devam “conversar”, deverá haver um caminho para a comunicação Diretor Matrícula Álgebra curso 3: insere aluno(Maria) Diretor Matrúcula curso Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 109 Diretor Matrícula incluiAluno(curso, AlunoInfo) Aluno nome nível Oferta Curso local abrir() incluirAluno(AlunoInfo) Professor nome StatusCadeira Algorítmo de Horário Formulário Matrícula curso nome NúmeroCréditos abrir() incluirAluno(AlunoInfo) Relacionamento: Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 110 Multiplicidade e Navegação: • Multiplicidade define como muitos objetos participam numa relação – Multiplicidade é o número de instâncias de uma classe que se relacionam a UMA instância de uma outra classe – Para cada associação e agregação, haverá duas decisões relativas a multiplicidade a se tomar: Uma para cada lado da relação • Apesar de associações e agregações serem bidirecionais por definição, freqüentemente é desejável restringir a navegação em uma única direção – Caso a navegação seja restringida, uma seta é adicionada para se indicar a direção da navegação Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 111 Multiplicidade e Navegação: Diretor Matrícula incluiAluno(curso, AlunoInfo) curso nome NúmeroCréditos abrir() incluirAluno(AlunoInfo) Aluno nome nível Oferta Curso local abrir() incluirAluno(AlunoInfo) Professor nome StatusCadeira Algorítmo de Horário Formulário Matrícula 0..* 1 1 0..* 1 1..* 3..10 1 4 0..4 Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 112 Herança • Herança é uma relação entre uma super-classe e suas subclasses • Há duas formas de se descobrir heranças: – Generalização – Especialização • Atributos comuns, operações, relações e/ou, são mostradas no nível aplicável mais alto da hierarquia nome Usuário Formulário Matrícula Algorítmo de Horário Diretor Matrícula incluiAluno(curso, AlunoInfo) Oferta Curso local abrir() incluirAluno(AlunoInfo) Aluno nome nível curso nome NúmeroCréditos abrir() incluirAluno(AlunoInfo) Professor nome StatusCadeira Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 113 O Estado de um Objeto • Um diagrama de transição de estados mostra – O ciclo de vida de uma classe – Os eventos que causam a transição de um estado para outro – As ações que resultam de uma mudança de estado • Diagramas de Transição de Estados são criados para objetos que tenham um comportamento dinâmico significante Iniciar Ação Abrir entrar: Registrar Aluno Sair: incrementa contador Fechado Cancelado fazer: Iiniciar curso fazer: Finalize curso fazer: Notificar Aluno Matriculado Incluir Aluno / Contador = 0 Inclui aluno[ contador < 10 ] [ contador = 10 ] Cancelar Cancelar Cancelar Diagrama de Transições de Estados Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 114 O Mundo Físico • Diagramas de Componentes ilustram a organização e dependências entre componentes de software • Um componente pode ser: – Um componente de código fonte – Um componente de runtime, ou – Um componente executável Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 115 Curso.class Oferta curso.class Aluno.class Professor.class Diagrama de Componentes curso.jar pessoa.jar curso Usuário Registro Cobrança Sistema Cobrança Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 116 Distribuindo o Sistema • O Diagrama de Distribuição mostra a configuração dos elementos de processamento runtime e dos processos que rodam dentro deles • O Diagrama de Distribuição visualiza a distribuição dos componentes através de toda a empresa Matrícula Database Biblioteca Salas Sede Principal Diagrama de Distribuição Estudo de Caso
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 117 Exercício O Hotel “Só quero Sossego” está precisando de sistema para automatizar suas principais atividades e facilitar o gerenciamento de suas operações. O hotel contém um número de apartamentos disponíveis para serem alugados aos hospedes. Cada apartamento tem as seguintes características: - Número, preços base, capacidade de pessoas - Tipo (Single, double, triplo ou suíte) O preço de cada apartamento está relacionado com seu tipo e sazonalidades (períodos especiais, tais como: férias, natal, carnaval...) Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de reserva do Hotel . As reversas devem ser registras no livro de reservas, que deve conter as seguintes informações: - Tipo de apartamento, período, duração da estadia e data da reserva. A reserva somente é confirmada após a verificação da disponibilidade do apartamento na data informada. O cliente deve receber as seguintes informações se confirmada a reserva: - Preço e detalhes sobre hotel. Caso contrário deve receber a informação que não foi possível fazer a reserva para data informada. Declaração do Problema:
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 118 - As reservas também podem ser feitas diretamente na Recepção do Hotel. No Check-in o hospede é identificado juntamente com sua reserva. No Check-out verifica-se todos os serviços prestados ao hospede e as despesas advindas desses serviços tais como: lavandeira, restaurante, telefonia, assim como a consumação do “frigobar”. O cliente poderá pagar a conta com cartão de crédito, dinheiro, cheque ou cheque de viagens. A disponibilidade deseja para o sistema é de 24x7 para Internet, as interfaces com usuários devem ser simples e sistema deve seguir o padrão de Identidade Visual (Manual de Identidade Visual). O sistema deve implementar um nível de segurança que garanta que somente o usuário que possuir uma senha (esta deve ser criptografa) poderá fazer alterações nos dados da reserva ou alterar seus cadastrais. Exercício: - Fazer o Diagrama de Caso de Reserva - Fazer o Diagrama de Seqüência - Fazer o Diagrama de Classes (Classes de Negócio) - Fazer o Diagrama de Projeto (Refinamento de Casses) - Fazer o Diagrama de Competentes Declaração do Problema (continuação): Exercício
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 119 Apêndice
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 120 SÍMBOLO GRÁFICO NOME DIAGRAMAS EM QUE APARECE USUALMENTE MODELO A QUE PERTENCEM ASSOCIAÇÂO DE AGREGAÇÃO Diagrama de Classes, Diagrama de Componentes. Classes de Objetos Componentes ASSOCIAÇÂO DE COMPOSIÇÃO Diagrama de Classes, Diagrama de Componentes. Classes de Objetos Componentes ASSOCIAÇÂO DE DEPENDÊNCIA Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Componentes, Diagrama de Implantação. Caso de Uso Classes de Objetos Componentes Componentes ASSOCIAÇÂO DE GENERALIZAÇÃO Diagrama de Casos de Uso, Diagrama de Classes. Caso de Uso Classes de Objetos ASSOCIAÇÂO REGULAR Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Componentes, Diagrama de Implantação. Caso de Uso Classes de Objetos Componentes Componentes ATOR Diagrama de Casos de Uso, Diagrama de Seqüência. Caso de Uso Caso de Uso CASO DE USO Diagrama de Casos de Uso. Caso de Uso CLASSE Diagrama de Classes. Classes de Objetos COMPONENTE Diagrama de Componentes Componentes Nome do Estado ESTADO Diagrama de Estados, Diagrama de Atividades. Classes de Objetos Caso de Uso ESTADO FINAL Diagrama de Estados, Diagrama de Atividades Classes de Objetos Caso de Uso Nome da Classe Atributos Operações Nome do Componente Apêndice A Notação UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 121 ESTADO INICIAL Diagrama de Estados, Diagrama de Atividades. Classes de Objetos Caso de Uso Nome da “Interface” ou “INTERFACE” Diagrama de Componentes Componentes INTERVALO DE EXECUÇÃO DE OPERAÇÂO Diagrama de Seqüência Caso de Uso MENSAGEM DE RETORNO Diagrama de Seqüência Caso de Uso MENSAGEM E CHAMADA DE OPERAÇÂO “Síncrona” Diagrama de Seqüência Caso de Uso MENSAGEM E CHAMADA DE OPERAÇÃO “Assíncrona” Diagrama de Seqüência Caso de Uso NÓ Diagrama de Implantação Componentes texto NOTA Em qualquer diagrama identificador:Classe ou :Classe OBJETO Diagrama de Seqüência, Diagrama de Atividades Caso de Uso Caso de Uso Nome do Pacote PACOTE Em qualquer diagrama em que é necessário representar um conjunto de coisas que devem estar agrupadas para efeito de uma organização apropriada TRANSIÇÃO DE ESTADO Diagrama de Estados, Diagrama de Atividades Classes de Objetos Caso de Uso AUTODELEGAÇÃO Diagrama de Seqüência Caso de Uso <<interface>> Nome da “Interface” Operação1 () Operação2 () Operação3 () Apêndice A Notação UML
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 122 Apêndice B UML 2.0 Visão Descreve Diagramas Visão de Requisitos Funcionais Requisitos funcionais do sistema pelo ponto de vista do usuário. diagramas de casos de uso Visão Estrutural Estática Estrutura estática do sistema. diagrama de classes diagrama de estruturas Visão de Comportamento Dinâmico Comportamento dinâmico do sistema, mostrando suas interações. diagramas de seqüências diagramas de atividades diagramas de estados Visões UML 2.0: Diagramas:
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 123 Notas: Marcas Registradas: Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou desmerecimento do produto/fabricante. É proibido o uso deste material para fins comerciais. Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail nós. Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail para nós. Rildo F dos Santos (rildosan@uol.com.br) Imagens: Google, Flickr e Banco de Imagem.
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 124 Licença:
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 125 Licença:
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UML 126 Marcas Registradas: Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou desmerecimento do produto/fabricante. Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail nós. Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail para nós. Rildo F dos Santos (rildosan@uol.com.br) Imagens: Google, Flickr e Banco de Imagem. Notas do autor
    • Linguagem de Modelagem Unificada © Copyright Rildo Ferreira, e-tecnologia.com, 2009 UMLUML - Linguagem de Modelagem Unificada