UML - Unified Modeling Language

[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”.