Upload
jefersonnerymota
View
37
Download
10
Embed Size (px)
DESCRIPTION
modelagem
Citation preview
Página 1
UMLUnified Modeling Language
Prof. Juliano Schimiguel
Página 2
Agenda
Histórico
A Guerra dos Métodos
Conceitos
Diagramas
Página 3
Histórico Com o surgimento do paradigma de orientação a
objetos - OO (a partir da metade da década de 70), começaram a surgir métodos alternativos de análise e projeto de sistemas;
Os conceitos de OO trouxeram uma nova filosofia de programação, em relação à técnica estruturada. Dessa forma, novos métodos eram necessários:
Classe Objeto Herança Encapsulamento Polimorfismo
Página 4
A Trajetória da UML Primeira proposta de linguagem orientada a objetos:
Smalltalk (Xerox Parc)
Surgimento do C++
Começou a surgir a preocupação de se criar métodos de projeto em orientação a objetos
Vários pesquisadores e grupos propuseram diferentes métodos de análise e projeto OO
Peter Coad e Ed Yourdon (Coad & Yourdon) Grady Booch (Booch) James Rumbaugh (OMT Object Modeling Technique) Ivar Jacobson (OOSE Object-Oriented Software
Engineering)
Página 5
A Guerra dos Métodos (1) As diferenças de notação entre os métodos gerou
problemas de comunicação entre pessoas e desenvolvedores que utilizavam diferentes técnicas
OMG (Object Management Group) tentou, sem sucesso, padronizar a notação
http://www.omg.org
Página 6
Qual a diferença entre um metodologista e um terrorista?
Com um terrorista, pode-se negociar; com um metodologista não...
A Guerra dos Métodos (2)
Página 7
O Nascimento da UML (1) Em 1994, James Rumbaugh sai da GE (General Electric) e se une à Grady Booch da Rational Software, com a
intenção de integrar seus métodos: Para a conferência OOPSLA’95, Grady e James prepararam a primeira descrição de seu método unificado
Ivar Jacobson se une à equipe;
Em 1996, eles (conhecidos como os TRÊS AMIGOS) lançam a primeira versão da UML
Página 8
O Nascimento da UML (2) A OMG decidiu padronizar os métodos
Várias organizações submeteram propostas: A Rational Software lançou a versão 1.0 da UML como proposta;
Após algumas “quedas-de-braço”, a versão 1.1 da UML foi adotada como padrão;
Em 1999, a versão 1.3 é tornada pública.
Página 9
O que é Linguagem de Modelagem?
É uma linguagem cujo vocabulário e regras têm seu foco voltado para a representação conceitual e física de um sistema a ser desenvolvido;
Questão Importante: A UML indica como criar e ler modelos, mas não aponta quais modelos deverão ser criados; Essa tarefa cabe ao processo de desenvolvimento de sistemas.
Página 10
Modelagem: Objetivos Guia para a construção do sistema;
Modelos documentam as decisões tomadas;
Linguagem comum entre os desenvolvedores;
Página 11
Uso de UML (1) Quão perfeitamente se deve seguir a linguagem de modelagem?
Isto depende da razão que se está utilizando a linguagem;
No caso de se estar utilizando uma ferramenta CASE para o desenvolvimento do sistema, deve-se aderir ao padrão da ferramenta: CASE (Computer Aided Software Engineer) - Engenharia de Software Assistida por Computador; São ferramentas que permitem o desenvolvimento de sistemas seguindo-se os conceitos de um determinado método; Permitem a geração automática de código: C++, Java, ...
Página 12
Uso de UML (2) No caso de uso dos diagramas para fins de comunicação entre pessoas:
Não se deve desviar muito da notação; A linguagem deve ser flexionada para contribuir na comunicação, e não a
comunicação entre as pessoas tem de ser alterada para o entendimento dos diagramas.
Página 13
Ferramentas CASE Rational Rose
http://www.rational.com/
TogetherSoft http://www.togethersoft.com/
ArgoUML (gratuita) http://argouml.tigris.org/
Gentleware Poseidon UML (gratuita) http://www.gentleware.com/
Página 14
Por que fazer Análise e Projeto? (1)
O produto final do processo de desenvolvimento de sistemas é o código executável:
Diagramas são, na verdade, apenas “figuras bonitas”? Nenhum usuário vai lhe agradecer pelas suas figuras bonitas!!!
Página 15
Por que fazer Análise e Projeto? (2)
Razões para utilizar UML: Facilidade na comunicação entre usuários e projetistas, e entre projetistas e programadores;
Utiliza-se UML para atingir uma certa precisão, sem se “perder” em detalhes, procurando salientar apenas aquelas informações que são importantes
Página 16
Por que fazer Análise e Projeto? (3)
A UML ajuda na obtenção de uma visão geral do sistema: A análise do diagrama de classes pode rapidamente
dizer que tipos de abstrações estão presentes no sistema.
Estado
Comportamento
Identidade
Página 17
Por que fazer Análise e Projeto? (4)
A medida que se examina mais profundamente o processo de desenvolvimento, pode ser necessário entender como as classes colaboram:
Nesse momento, faz-se uso dos diagramas de interação, que ilustram os comportamentos-chave do sistema;
Página 18
Conceito de UML A UML é um linguagem de modelagem gráfica destinada a ...
Visualizar Especificar Construir Documentar
... os artefatos de um sistema complexo de software.
Neste contexto, artefato é um conjunto de informações utilizado ou produzido por um processo de desenvolvimento de software.Neste contexto, artefato é um conjunto de informações utilizado ou produzido por um processo de desenvolvimento de software.
Página 19
Linguagem para Visualização
Para muitos programadores, não existe diferença entre pensar e implementar um código;
A UML é muito mais que um “punhado” de símbolos gráficos. Por trás de cada símbolo gráfico, existe uma representação bem definida;
Um desenvolvedor poderá usar a UML para escrever seu modelo e qualquer outro desenvolvedor será capaz de interpretá-lo.
Página 20
Linguagem para Especificação
Especificar significa construir modelos precisos, sem ambigüidades e completos;
Atender a todas as decisões importantes em termos de análise, projeto e implementação.
Página 21
Linguagem para Construção Não é uma linguagem visual de programação, mas seus modelos podem ser diretamente conectados a várias linguagens de
programação; É possível mapear os modelos da UML em linguagens de programação tais como Java, C++, Visual Basic ou até tabelas de banco
de dados relacionais; Permite a realização de uma engenharia de produção: a geração de código a partir de um modelo em UML; Permite a engenharia reversa, construir um modelo a partir de sua implementação.
Página 22
Linguagem para Documentação
Uma empresa de software produz vários tipos de artefatos, além do código executável bruto: Requisitos Projeto Código-fonte Testes Protótipos
Estes artefatos não são apenas partes do processo, mas também são críticos para controlar.
Página 23
Onde pode ser usada? Destina-se principalmente a sistemas complexos de software; Tem sido empregada em domínios como:
Sistemas de Informações corporativos Serviços bancários e financeiros Telecomunicações Transportes Defesa/Espaço Aéreo Eletrônica médica Serviços distribuídos baseados na Web
É suficientemente expressiva para modelar sistemas que não sejam de software.
Página 24
Os Conceitos da UML A UML pode ser utilizada para:
Mostrar o uso de um sistema e suas funções usando Casos de Uso e Atores; Ilustrar a concretização de Casos de Uso com Diagramas de Iterações; Representar a estrutura estática de um sistema usando Diagramas de Classes; Modelar o comportamento de objetos com Diagramas de Transições de Estado; Revelar a arquitetura de implementação física com Diagramas de Componentes e Distribuição.
Página 25
Colocando a UML para funcionar
Uma Universidade quer informatizar seu sistema de matrícula: A Secretaria produz o currículo para o semestre:
• Um curso pode ter múltiplas matérias Os Alunos selecionam 4 matérias principais e 2 matérias 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 ou remover matérias por um determinado período após a matrícula; Os Professores usam o sistema para receber a lista de oferta de cursos.
Página 26
Atores Um Ator é alguém ou alguma coisa que deve interagir
com o sistema a ser desenvolvido
Aluno
Secretaria
Professor
Sistema Cobrança
Página 27
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árioManter Curriculum Solicitar Lista de Cursos
Página 28
Diagrama de Casos de Uso Diagramas de casos de uso são criados para se
visualizar a relação entre atores e casos de uso
Aluno
Secretaria
Professor
Mantém seu Horário
Mantém Curriculum
Solicita Lista de Cursos