Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar, construir e documentar os artefatos de um sistema de software. É utilizada para entender, projetar, navegar, configurar, manter e controlar informação sobre tais sistemas. FMR 2
UML Ponto de Vista É pretendido para usar com todos métodos de desenvolvimento, estágios de ciclo de vida, domínios de aplicação e media. O objetivo da Linguagem de Modelagem é para unificar experiências passadas sobre técnicas de modelagem e incorporar software recente com melhor prática em uma abordagem padrão. FMR 3 UML Inclui conceitos semânticos, notações e guidelines. Possui partes estática, dinâmica, ambiental e organizacional. É suportada por ferramentas de modelagem visual (RUP, Catalise) que tem gerações de código e emissão de relatórios. FMR 4
UML Suporta um processo de desenvolvimento OO e sua especificação não define um processo padrão, porem pode ser usada em um processo de desenvolvimento iterativo. Ela captura informações sobre a estrutura estática e comportamento dinâmico de um sistema. FMR 5 Item O que é Modelagem Visual? Order Modelagem captura as partes essenciais do sistema. Dr. James Rumbaugh Ship via Processo de negócio Modelagem Visual é modelagem usando notações gráficas padrões Sistema de Computador FMR 6
Modelagem Visual Captura os Processos de Negócio Análise de Use Case é uma técnica utilizada para capturar o processos de negócio das perspectivas do usuário. FMR 7 Modelagem Visual é uma Ferramenta de Comunicação Usar modelagem visual para capturar objetos de negócio e lógica de negócio Usar modelagem visual to analisar e projetar sua aplicação FMR 8
Modelagem Visual Controla a Complexidade FMR 9 Modelagem Visual Define a Arquitetura de Software Interface do usuário (Visual Basic, Java) Lógica de negócio (C++, Java) Servidor do Banco de Dados (C++ & SQL) Modele seu sistema independente da linguagem de implementação FMR 10
A Modelagem Visual Promove Reuso Múltiplos Sistemas Componentes Reusáveis FMR 11 O quê é a UML? UML significa Linguagem de Modelagem Unificada A UML combina o melhor dos melhores de Conceitos de Modelagem de Dados (Diagramas de Relacionamento de Entidade) Modelagem de negócio (work flow) Modelagem de Objetos Modelagem de Componente A UML é a linguagem padrão para visualizar, especificar, construir, e documentar os artefatos de um sistema intensivo de software Ele pode ser usado com todos processos, através do ciclo de vida do desenvolvimento, e através de tecnologia de implementação diferente. FMR 12
História da UML Nov 97 UML é aprovada pela OMG FMR 13 A UML Suporta Desenvolvimento de Aplicações ORDBMS Oracle Objetos Classes Objetos de Negócio Relacionamentos Sistemas de Larga escala Particionamento de aplicações Components Microsoft Use Cases ActiveX/COM Microsoft Cenários Processos de Negócios CORBA OMG FMR 14
Conceitos da UML A UML pode ser usada para: Exibir os limites do sistema e suas maiores funções usando use cases e atores Ilustrar realizações de use case com Diagramas de Interação Representar uma estrutura estática de um sistema usando Diagramas de Classe Modelar o comportamento de objetos com Diagramas de Transição de Estado Revelar a arquitetura de implementação física com Diagramas de Componentes e Distribuição Estender sua funcionalidade com Estereotipo. FMR 15 Colocando a UML para Funcionar A Universidade XXX quer informatizar seu sistema de matrícula A secretaria registra o currículo para um semestre Um curso pode ter múltiplas matérias Estudantes selecionam 4 matérias principais e 2 alternativas Após o registro, 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/remover matérias por um determinado período após a matrícula. Os Professores usam o sistema para receber sua lista de cursos oferecidos; Os Usuários do sistema de matrícula são atribuídos passwords que são usados na validação do logon FMR 16
Atores Um Ator é alguém ou alguma coisa que deve interagir com o sistema a ser desenvolvido Secretaria Professor Estudante Sistema de Faturamento FMR 17 Use Cases Um use case é um padrão de comportamento para exibir o sistema Cada use case é uma seqüência de transações relacionadas executada por um ator e o sistema em um diálogo. Atores são examinados para determinar suas necessidades Secretaria-- manter o currículo Professor -- solicitar lista de cursos Estudante -- manter o horário de aulas Sistema de Cobrança -- recebe informações sobre cobrança de matrícula. Manter Currículo Solicitar Lista de cursos Manter horário FMR 18
Documentando Use Cases Um documento de fluxo de eventos é criado para cada use cases Escrito do ponto de vista de um ator Detalha o que o sistema deve fornecer para o ator quando o use case for executado Conteúdos típicos Como o use case começa e termina Fluxo normal de eventos Fluxo alternado de eventos Fluxo excepcional de eventos (respostas a erros) FMR 19 Fluxo de Eventos - Manter Currículo Esse use case começa quando a Secretaria loga no Sistema de Matrícula e entra com password. O sistema verifica se o password é valido (E-1) e sugere a Secretaria para selecionar o semestre corrente ou um semestre futuro (E-2). A Secretaria entra com o semestre desejado. O sistema solicita qual a atividade desejada: INCLUIR/APAGAR/ MODIFICAR/SAIR. Se a atividade selecionada for INCLUIR, o S-1: O Sub-fluxo Adiciona uma matéria é executado. Se a atividade selecionada for APAGAR, o S-2: O Sub-fluxo Apaga uma Matéria é executado. Se a atividade selecionada for MODIFICAR, o S-3: O subfluxo Modifica uma Matéria é executado. Se a atividade selecionada for SAIR, o use case termina.... FMR 20
Diagrama Use Case Diagramas use case são criados para visualizar o relacionamento entre atores e use cases Lista de cursos solicita Aluno Professor Mantém Planejamento Sistema de Cobrança Manter currículo Secretaria FMR 21 Usar e Estender relacionamento Use Case A medida que os use cases são documentados, outros relacionamento de use case podem ser descobertos Um relacionamento de uso mostra o comportamento que é comum a um ou mais use cases Um relacionamento estendido mostra comportamento opcional <<usa>> Matrícula para cursos <<usa>> Validação senha Manter currículo FMR 22
Realização de Use Case O diagrama use case apresenta uma visão externa do sistema Diagramas de Interação descrevem como use cases são realizados como interações entre associações de objetos Dois tipos de Diagramas de Interação Diagramas de Seqüência Diagramas de Colaboração FMR 23 Diagramas de Seqüência Um diagrama de Seqüência exibe interações de objetos ordenados numa seqüência temporal : Aluno Formulário De matr. Gerente de matricula Matemática Básica math 101 Álgebra 1 1: preenche 2: envia tempo 3: curso (gabriel, matemática) 4: está aberto? 5: está aberto?? 6: inclui (gabriel) 7: inclui (gabriel) FMR 24
Diagrama de Colaboração Um Diagrama de Colaboração exibe as interações de objetos organizadas em torno dos objetos e seus links de um para o outro. 1: pega informação do curso 2: processa curso form. : cursoform : Secretária 3: inclui curso Curso: : curso Diretor: : Diretor do Curso 4: novo curso FMR 25 Diagramas de Classe Um Diagrama de Classe mostra a existência de classes e seus relacionamentos com a visão lógica de um sistema. Elementos de modelagem da UML presentes nos Diagramas de Classes: Classes, suas estruturas internas e comportamento Associações, agregações, dependências, e relacionamento de herança Multiplicidade e indicadores de navegação Nomes de papéis (o que uma classe representa para outra FMR 26
Classes Uma classe é um conjunto de objetos com estruturas, comportamento, relacionamento e semânticas 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 Classes devem ser nomeadas usando o vocabulário de domínio. Padrões de nomenclatura devem ser estabelecidos Ex: todos nomes de classes são substituídos no singular, iniciando com letra maiúscula. FMR 27 Classes Diretor de Matrícula Algoritmo de Horário Formulário de Matricula Aluno Curso Professor Oferta Curso FMR 28
Operações O comportamento de uma classe é representado pelas suas operações Operações podem ser encontradas examinando os Diagramas de Interação Matrícula form Matrícula Gerente Diretor de Matrícula 3: Matricula curso (gabriel, matemática) Matricula (Aluno, matéria) FMR 29 Atributos A estrutura de uma classe é representada pelos seus atributos Atributos podem ser encontrados pelo exame das definições de classes, requisitos de problemas, e pela aplicação do domínio de conhecimento Cada curso oferecido possui um número, local e horário Oferta de Curso Número local horário FMR 30
Classes Diretor de Matrícula Algoritmo de Horário IncluiAluno(curso,Aluno Info) Formulário de Matricula Nome nível Aluno Curso Nome MúmeroCréditos Abrir() incluiraluno(alunoinfo) Professor Nome StatusCadeira Oferta Curso local Abrir() incluir Aluno(AlunoInfo) FMR 31 Relacionamento Relacionamento fornece um caminho para comunicação entre objetos Diagramas de Seqüência e/ou Colaboração são examinados para determinar quais links entre os objetos precisam existir para alcançar o comportamento desejado-- Caso dois objetos precisem conversar deverá haver um link entre eles. Três tipos de relacionamentos: Associação Agregação Dependência FMR 32
Relacionamentos Uma associação é uma conexão bi-direcional entre classes Uma associação é mostrada como uma linha conectando as classes relacionadas Uma agregação é um tipo mais forte de conexão, onde o relacionamento está entre o todo e suas partes Uma agregação é mostrada como uma linha conectando as classes relacionadas com um losango perto da classe que representa o todo. Um relacionamento de dependência é uma forma mais fraca de relacionamento mostrando uma relação entre um cliente e um fornecedor onde o cliente não têm conhecimento semântico do fornecedor. Uma dependência é mostrada como uma linha pontilhada entre o cliente e o fornecedor. FMR 33 Descobrir Relacionamentos Relacionamento são descobertos por diagramas de interação Se dois objetos deve falar aí deve ser um caminho para comunicação Diretor de Matricula Algebra curso Diretor Matrícula 3: insere aluno(gabriel) curso FMR 34
Relacionamento Formulário Matricula Algoritmo de horário Diretor Matrícula incluialuno(curso,alunoinfo) Aluno nome nível Curso nome NúmeroCrédito abrir() incluiraluno(alunoinfo) Professor nome StatusCadeira Oferta de Curso local abrir() incluiraluno(alunoinfo) FMR 35 Multiplicidade e Navegação Multiplicidade define como muitos objetos participam de um relacionamento Multiplicidade é o número de instâncias de uma classe relacionada para UMA instância de outra classe Para cada associação e agregação, existem duas decisões de multiplicidade para fazer: um para cada lado da relação Apesar das associações e agregações serem bi-direcionais por definição, freqüentemente é desejável restringir a navegação em uma única direção. Caso a navegação seja restrita, uma ponta da seta será adicionada para indicar a direção da navegação FMR 36
Multiplicidade e Navegação Formulário de Matrícula Algoritmo de Horário Professor Nome StatusCadeira 0..* 1 1 Diretor Matrícula incluialuno(curso, AlunoInfo) Aluno Nome nível 3..10 1 4 0..4 0..* 1..* Oferta Curso local abrir() incluiraluno(alunoinfo) Curso nome NúmeroCréditos abrir() incluiraluno(alunoinfo) 1 FMR 37 Herança Herança é uma relação entre uma superclasse e suas sub-classes Existem duas formas para descobrir heranças: Generalização Especialização Atributos comuns, operações, e/ou relacionamentos são mostrados em níveis de aplicação mais alto na hierarquia. FMR 38
Herança Formulário de Matrícula Algoritmo de Horário Usuário nome Diretor Matrícula incluialuno(curso, AlunoInfo) Aluno Nome nível Curso nome NúmeroCréditos abrir() incluiraluno(alunoinfo) Professor Nome StatusCadeira Oferta Curso local abrir() incluiraluno(alunoinfo) FMR 39 O Estado de um Objeto Um diagrama de transição de estado mostra A ciclo de vida de uma classe Os eventos que causa a transição de um estado para outro As ações resultantes de uma mudança de estado Diagrama de Transição de Estados são criados por objetos com comportamento significativamente dinâmico. FMR 40
Diagrama de Transição de Estados Iniciar Ação Fazer iniciar curso cancelar Incluir Aluno / Contador = 0 Cancelar Inclui aluno [contador < 10] Abrir Entrar: Registrar Aluno Sair: incrementa contador Contador = 10 Cancelado Notificar Aluno matriculado Cancelar Fechado Finalize Curso FMR 41 O Mundo Físico Diagramas de Componentes ilustram as organizações e dependências entre as componentes de software Um componente pode ser Um componente de código fonte Um componente em tempo de execução ou Um componente executável FMR 42
Diagrama de Componente Cobrança.exe Registro.exe Sistema de Cobrança Curso.dll curso Pessoas.dll Usuários Aluno Professor Curso Oferta curso FMR 43 Distribuindo o Sistema O Diagrama de Distribuição mostra a configuração dos elementos de processamento em tempo de execução e dos processos que rodam dentro deles O Diagrama de Distribuição visualiza a distribuição dos componentes através de toda a empresa. FMR 44
Diagrama de Disposição Matricula Database Biblioteca Sede Principal Salas FMR 45 Estendendo a UML Estereótipos podem ser usados para estender os elementos de notação da UML Estereótipos podem ser usados para classificar e estender associações, relacionamentos de heranças, classes, e componentes Exemplos: Estereótipos de Classe: limite, controle, entidade, utilidade, exceção Estereótipos de herança: usam e estende Estereótipos de componentes: subsistema FMR 46
O que o Ciclo de Vida Iterativo Não é Ele não é picado hacking ; Ele não é uma caixa de brinquedo para os desenvolvedores brincarem; Ele não é imprevisível; Ele não é re-projetar a mesma coisa várias vezes até atingir a perfeição Ele não é uma desculpa para não planejar e gerenciar um projeto; Ele não é algo que afeta somente o desenvolvedor do projeto; FMR 47 O que o Ciclo de Vida Iterativo É Ele é planejado e gerenciado; Ele é previsível; Ele acomoda mudanças de requisitos com pouca quebra; Ele é baseado em emissão de protótipos executáveis em constante evolução e, não apenas na documentação; Ele envolve o cliente/usuário por todo o processo Ele é dirigido pelos riscos envolvidos FMR 48
Três Importantes Características da Abordagem Iterativa Integração contínua Não é feita de uma vez próximo a data de entrega. Versões freqüentes e executáveis Algumas internas; algumas entregues aos clientes Ataca riscos através de progresso demonstrado Progresso é medido na funcionalidade do produto final e não em documentação ou estimativas da Engenharia. FMR 49 Referências Bibliográficas Http://www.rational.com/uml/tutorials2.html Pressman, R. S. - Engenharia de Software - Ed. 3 -Mak-1994 FMR 50
FMR 51