Paraajudaraprotegersuaprivacidade,oPowerPointimpediuo downloadautomáticodestaimagemexterna.Parabaixareexibirestaimagem,cliqueemOpçõesnaBarradeMensagensecliqueemHabilitarconteúdoexterno.
Orientaç Orie ntação ão a Obje Objetos tos – Resu Resumo mo da da UML UML
Tópicos:
Introdução e histórico 1) Diagrama de Casos de Uso 2) Diagrama de de Cl Classes 4) Dia iagr gram amaa Tra Trans nsiiçã çãoo de de Est Estad ados os 5) Diagram amaa de Atividades agra ag ram ma e om ompo pone nenn es 7) Diagrama de de Im Impl pleementaç açãão
Objetivo: Fornecer uma n ro uç o so re a – n e Modeling Language, através da apresentação dos diagramas mais importantes dessa linguagem de modelagem.
UML
Introdução e histórico
Objetivo: Fornecer uma introdução sobre UML – Unified Modeling Language, através da apresentação dos diagramas mais importantes dessa linguagem de modelagem.
Ivar Jacobson, James Rumbaugh e Grandy Booch foram os autores iniciais que unificaram três “métodos”: a OOSE, a OTM e o método Booch.
Em 1997 a Object Management Group (OMG), definiu a UML como linguagem padrão par araa a modelag ageem OO. [sit [s itee of ofic icia iall http://www.uml.org/ ]
UML não é um método. Ela não possui um fluxo de trabalho para orientar o engenheiro de software, ela possui somente a definição dos diagramas reccom re omen enddad ados os.. O mé méto todo do as asso soci ciad adoo é den enom omin inad adoo Rational Unified Process. Principais diagramas utilizados pela UML são: Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Seqüência, Diagrama Transição de Estad adoos, Dia iaggram amaa de Atividades, Dia iaggram amaa de Componentes e Dia iagr gram amaa de
2
UML
Introdução e histórico
Versão mais recente (março/2003) = UML 1.4.1 + Action Semantics
UML 1.5 .
– OMONDO – www.eclipseuml.com) UML 1.3
Junho/1999 (UML User Guide) Outras empresas se juntam ao Consórcio - 1997 Primeira submissão à OMG – Jan/1997 ” ” Junho/1996
OOPSLA - 1995
UML 1.0
UML 0.9
Unified Method
UML 1.1
0.8
1994
UML User Guide
Modelagem - princípios
A mo e agem a parte centra as ativi a es o processo de requisitos de um bom desenvolvimento de software.”
A principal finalidade da modelagem é comunicar o enten imento que temos o sistema que estamos construin o. A principal finalidade do software é atender as necessidades dos usuários e do negócio.
1) A escolha de quais modelos criar tem grande influência sobre como um problema é atacado e como a solução é . 2) Qualquer modelo pode ser expresso por diferentes níveis de precisão. 3) Os melhores modelos são os conectados a realidade. 4) Um único modelo não é suficiente. Um sistema complexo é melhor abordado através de um e ueno ru o de modelos independentes.
4
UC - Use Cases
1) Diagrama de Casos de Uso
o e a uma unciona i a e o sistema, É descrito sob a forma de interações entre o ator e o sistema. É sempre iniciado por um ator primário e provê algo de valor ang ve para esse a or. Por ser descrito preferencialmente sob a forma textual, ele pode ser utilizado com a idéia de contrato e para a comunicação entre os “ ” Um caso de uso é formado por cenários de sucesso e de fracasso. ATOR Abstração do ambiente externo do sistema. , , , que usa o sistema.
AS
S
UC 1
or UC 2 Especificação do Caso de Uso
5
UC - Use Cases
1) Diagrama de Casos de Uso caso de uso
Fazer matrícula
relacionamento
“estende”
6 ator
Apresentar débitos
Aluno Encerrar matrículas
Consultar “inclui” “inclui” Professor
Autentica r
Fornecer notas Sistema de Adm. Cursos comunicação – a direção indica quem iniciou
Secretaria
UC - Use Cases
1) Diagrama de Casos de Uso
Objetos - Classes
2) Diagrama de Classes
Mostra classes, interfaces, colaborações e relacionamentos. 1) envolve a modelagem do vocabulário do sistema. 2) faz a modelagem da visão estática do sistema. 3) instâncias de objetos são povoadas na classe desse objeto. 4) um objeto encapsula suas informações e seu comportamento.
nome a c asse
Aluno nome: Nome endereço: string telefone: numérico adicionarAluno obterTodosAlunos
atributos
8
Objetos - Classes
2) Diagrama de Classes
9
agregação 0..1
tem Escola
é responsavel tem por
Departamento 1..*
1..*
1..* promove
é membro de
generalização
é atribuido a 1..*
* fre uenta
ministra
Aluno
* AlunoMatric
Instrutor
Curso
*
*
* AlunoAvulso
0..1
*
1..*
associação Avaliação
Mensagens
3) Diagrama de Seqüência
Diagrama de Colaboração através das mensagens trocadas entre eles. •
na a e proce er a represen aç o o funcionamento do sistema e, assim, encontrar alguma omissão cometida nos modelos anteriores.
10
Introdução
3) Diagrama de Seqüência
11
Objeto 1:
Objeto N:
Nome da classe
Nome da classe
Classe do ator
1. evento
2. operação
3. operação lista de parametros
Texto descritivo
4. operação 5. evento
Possui se üência tem oral; a resenta a linha de vida do ob eto e um retângulo estreito que representa a duração da ação desempenhada.
3) Diagrama de Seqüência condição
objeto A se novo <>
mensagem síncrona
objeto B
objeto
Mensagem barra de ativação
valor de retorno
au o e egaç o
símbolo de destrui ão
Tempo (top-down)
<> linha de vida
12
3) Diagrama de Colaboração Faz ênfase à organização do caminho das mensagens e representa a seqüência temporal através da numeração das mensagens . 1. evento
Objeto 1:
. (lista de parâmetros)
2. operação Objeto 2
Nome da classe
nome do ator Classe do ator
4. operação (lista de parâmetros) 5. operação (lista de parâmetros) Objeto 3
fluxo de objeto
:Nome da classe
13
StateChart
4) Diagrama Transição de Estados
O DTE é utilizado para modelar o aspecto dinâmico dos casos de uso e para mapear o ciclo de vida de objetos. 1) representa, como uma máquina de estados, o ciclo de vida de um objeto importante para o sistema ou o comportamento de um caso de uso. 2) é utilizado também para construir o software. 3) um estado é uma situação “estática” (do objeto ou do UC) que somente será alterada se alguma condição for ativada (por um evento externo ou por uma necessidade de resposta temporal). um evento spara uma trans ç o e esta os. 5) só inicie seu diagrama após identificar a maioria dos estados e das transições TRANSIÇ O: é um relacionamento de mudança entre dois estados, provocada por um evento pré-determinado. ESTADO: é uma situação ou condição na vida de um objeto.
14
DTE
4) Diagrama Transição de Estados Excluiu pilha Excluir pilha / Deletar pilha Mensagem "Pilha excluida"
Criou pilha Criar pilha / Criar nova pilha Mensagem "Pilha criada"
Pilha vazia f:Colocou elemento Incluir / Colocar elemento Mensagem "Operação OK" Retirou elemento Retirar / Retirar elemento Mensagem "Operação OK"
Retirou elemento Retirar / Mensagem "Pilha vazia" Retirou elemento Retirar / Retirar elemento Mensagem "Operação OK"
Pilha carregada f:-
Colocou elemento Incluir / Colocar elemento Mensagem "Operação OK"
Colocou elemento Incluir /
Retirou elemento Retirar /
Mensagem "Operação OK"
Mensagem "Operação OK"
Pilha cheia -
Colocou elemento Incluir / Colocar elemento Mensagem "Pilha cheia"
15
activities
5) Diagrama de Atividades
O Diagrama de Atividades também é utilizado para modelar aspectos dinâmicos do sistema. O diagrama de atividades: 1) é essencialmente um fluxograma que modela o fluxo de controle , . 2) é utilizado para especificar e comunicar o encadeamento das atividades dos usuários quando esses interagem com o sistema. represen a ram caç es a rav s e urcaç es e unç es a rav s de barras de sincronização. 4) é um tipo de diagrama de transição de estados onde a transição é . 5) deve ser elaborado 1 diagrama para cada caso de uso.
16
activities
5) Diagrama de Atividades Laboratório
Paciente
Médico
17 raias
início c asse envo v a Consulta
Consulta Marcar consulta
bifurcação
Caso de Uso: ATENDER PACIENTE
Prescrever receita [exames não] [exames sim]
Paciente
Paciente
Pedir exames
atividade
Atualizar exames
Fazer exames
Finalizar consulta
término
barra de sincronização
6) Diagrama de Componentes
18
- Retrata os componentes de software e suas dependências. Componente fonte: é tipicamente o arquivo de código fonte de implementação de uma ou mais classes. Componente binário: é o código objeto que é resultado da compilação de um componente fonte. Ele pode ser um arquivo com o código objeto, uma biblioteca estática ou uma biblioteca dinâmica. Componente executável: é um arquivo de programa executável que é resultado da “link-edição” de componentes binários ( estático, na hora de link, ou dinâmico, na hora de executar). um elevador at o an ar c ama o. - Documenta o empacotamento físico das classes. -
.
6) Diagrama de Componentes
19
Manuseador de Janelas ManJanel.c Manuseador de Janelas (ManJanel.obj) BibliotecaGrafica (BGrafica.dll)
Manuseador Comum (ManComum.cpp) Comum (ManComum.obj)
ProgramaCliente (PCliente.exe) Classe Principal (Principa.cpp) Classe Principal (Principa.obj)
7) Diagrama de Implementação - Mostra a configuração de nós de processamento em tempo de execução e os componentes de software que existem nesses nós.
: caixa
<<10-T Ethernet>>
fechamento.exe pagamento.exe
principal : server
<<10-T Ethernet>> : administração . aluguel.exe
vel.= 300mHz mem.=128 megas BD-patins.exe SistPatins.exe
<<10-T Ethernet>>
: atendimento Reserva.exe aluguel.exe
20
BIBLIOGRAFIA
21
Booch, Grandy; Jacobson, Ivar; Rumbaugh, James; The Unified Modeling Language User Guide; The Addison-Wesley Object Technology Series, (1999). ressman, . .; ngen aria e o tware, c raw(2006), ISBN 0-07-28318-2.
, ar cover, t e t on,
Sommerville, I.; Engenharia de Software, 8a edição; Pearson Addison-Wesley - - - .