UML - Unified Modeling Language
Por: Tailan Patrick • 28/5/2016 • Trabalho acadêmico • 1.548 Palavras (7 Páginas) • 292 Visualizações
[pic 1]
FUNDAÇÃO DE EDUCAÇÃO PARA O TRABALHO DE MINAS GERAIS
Curso Técnico em Informática
UML
TAILAN PATRICK RODRIGUES
Belo Horizonte
2015
TAILAN PATRICK RODRIGUES
UML
Trabalho apresentado à disciplina Fundamentos de Analise de Sistemas.
Professor: Albert
2ª etapa – Turno manhã
Belo Horizonte
2015
SUMÁRIO
1 INTRODUÇÃO 04
2 OS DIAGRAMAS ESTRUTURAIS 04
2.1 Diagrama de Classes 04
2.2 Diagrama de Objetos 04
2.3 Diagrama de Componentes 05
2.4 Diagrama de Pacotes 05
2.5 Diagrama de Estruturas 05
3 DIAGRAMA DE CASOS DE USO 05
4 CONCLUSÃO 10
5 REFERÊNCIAS 11
1 INTRODUÇÃO
UML é um acrônimo para Unified Modeling Language, que no português significa Linguagem Unificada de Modelagem. Trata-se de uma linguagem de modelagem padrão na programação orientada a objetos.
Surgiu no final de 1995, e graças a uma união de três metodologias de modelagem que eram: o método de Grady Booch, o método OMT(Object Modeling Technique) de um sueco chamado Ivar Jacobson e o método OOSE que significa Object-Oriented Software Engineering do americano James Rumbaugh.
Não se trata de um método de desenvolvimento, e sim como já dito, é algo bem diferente que se chamamos de modelagem. Ela é usada para permitir ao desenvolvedor visualizar a comunicação entre objetos através de desenhos e diagramas em um padrão definido, e é muito usada para criar modelos de software. Apesar de representar software através de modelos orientados a objetos ela não demonstra que tipo de trabalho deve ser feito.
2 OS DIAGRAMAS ESTRUTURAIS
Os diagramas estruturais são utilizados para visualizar, especificar, construir e documentar aspectos estáticos de um sistema.
2.1 Diagrama de Classes
Este tipo de diagrama tem o foco em representar as classes de negócio, interfaces e outros sistemas de classes de controle. Ele é considerado o mais importante na UML, pelo fato de oferecer apoio aos demais diagramas.
2.2 Diagrama de Objetos
O diagrama de objetos tem como objetivo representar os objetos e seus relacionamento, como definido no Diagrama de Classes. Estes objetos e suas instâncias demonstrados são utilizados para conseguir a visão do projeto de um sistema, a partir de situações que ocorrem na vida cotidiana, ou melhor no mundo real.
2.3 Diagramas de Componentes
Este diagrama é bastante utilizado em casos em que há muita ligação entre partes do hardware e software. Ele modela os recursos de infraestrutura em geral ou artefato de sistemas. Cada nó ou parte deste diagrama é uma unidade física que representa um recurso do computador, como roteadores, dispositivos de entrada e também e saída, processadores ou seja, qualquer equipamento que tenha importância para o software proposto.
2.3 Diagrama de Pacotes
Ele tem objetivo de representar subsistemas que cercam um software, determinando as partes que compõem o mesmo. Ele está muito relacionado com o diagrama de classes e detalha as classes que estão presentes em um pacote.
2.4 Diagramas de Estrutura
Utilizados para fazer modelagem de colaborações, que consistem em descrever uma visão de um conjunto de instâncias que cooperam entre si, com o objetivo de executar determinada tarefa.
Concluindo os diagramas estruturais, vemos que eles são responsáveis por definir a estrutura do sistema que esta para ser modelado e desenvolvido, tanto no software como no hardware, nem todos estes diagramas estruturais são necessários para uma documentação de um software, pois na verdade são selecionados os diagramas estruturais e as suas combinações que irão ser utilizados no projeto e torna-se importante para obter uma modelagem mais eficiente.
3 DIAGRAMAS DE CASOS DE USO
Este é o diagrama que documenta o que faz o sistema, de acordo com o ponto de vista de que usa este sistema. De modo simplificado ele descreve quais são as principais funcionalidades do sistema e a interação dessas tais funcionalidades com os usuários. Não se aprofundam em detalhes técnicos.
Ele se origina da especificação de requisitos, que não tem nada a ver com a UML. Pode ser utilizado também para criar o documento desses requisitos.
São compostos por quatro partes essenciais:
O Cenário: Sequência de eventos que acontecem quando um usuário interage com o sistema.
O Ator: Ou melhor, o perfil de usuário do sistema.
Use Case: É uma funcionalidade ou até mesmo uma tarefa realizada pelo ator, como já dito que significa o usuário.
Comunicação: É o que liga um ator (usuário) com um caso de uso.
Darei um exemplo de cenário (fonte do caso de uso no fim do trabalho):
“A clínica médica Saúde Perfeita precisa de um sistema de agendamento de consultas e exames. Um paciente entra em contato com a clínica para marcar consultas visando realizar um check-up anual com seu médico de preferência. A recepcionista procura data e hora disponível mais próxima na agenda do médico e marca as consultas. Posteriormente o paciente realiza a consulta, e nela o médico pode prescrever medicações e exames, caso necessário”.
...