Visual Modeling and the UMLA Universidade pretende desenvolver um Sistema de Inscrições
A Secretaria Académica prepara o curriculum de disciplinas para um semestre
Uma área vocacional oferece várias disciplinas
Cada Estudante selecciona 6 disciplinas, 4 da sua área vocacional e 2 de uma área de opção
Assim que o estudante faz a sua inscrição a Contabilidade é notificada e o valor é contabilizado na conta do estudante.
Os estudantes podem utilizar o Sistema de Inscrições para alterar as disciplinas escolhidas durante um certo periodo após a inscrição
Os professores utilizam o sistema para aceder á lista dos candidatos inscritos nas disciplinas que oferecem.
Os utilizadores do Sistema de Inscrições possuem senhas (passwords) que são utilizadas para validar o acesso.
Page *
R
Actores
Um actor é alguém ou algo que tem de interagir com o sistema que está a ser desenvolvido
Estudante
Secretaria
Académica
Professor
Contabilidade
Page *
R
Use Cases
Um “use case” é um padrão de comportamento que o sistema exibe; pode ser associado a um serviço que é disponibilizado.
Cada “use case” é uma sequencia de transações relacionadas, executadas num diálogo entre um actor e o sistema
Os actores são identificados para que se determinem as suas necessidades
Secretaria Académica -- manter curriculum de disciplinas
Professor -- solicitar lista de candidatos inscritos
Estudante -- inscrever em disciplina
Fazer inscrição
Manter Curriculum
Manter Curriculum
Este “use case” inicia-se quando a Secretaria Académica acede ao Sistema de Inscrições e fornece a sua password. O sistema verifica que a password é valida (E-1) e notifica a Secretaria Académica para seleccionar o semestre corrente ou um semestre futuro (E-2). A Secretaria insere o semeste pretendido. O sistema solicita à Secretaria Académica que seleccione a operação que pretende realizar: ADICIONAR, REMOVER, REVER ou TERMINAR.
Se a actividade selecionada for ADICIONAR inicia-se o subfluxo S-1: Adicionar uma disciplina.
Se a actividade selecionada for REMOVER inicia-se o subfluxo S-2: Remover uma disciplina.
Se a actividade selecionada for REVER inicia-se o subfluxo S-3: Rever curriculo.
Se a actividade for QUIT, o “use case” termina.
Page *
R
Diagrama de “Use Case”
Os diagramas de “Use case” são criados para visualizar as relações entre os actores e os “use cases”
Estudante
Concretização do “Use Case”
O diagrama de “use case” apresenta uma visão externa do sistema
O diagrama de interacção descreve o funcionamento do “use cases” através das interacções entre comunidades de objectos.
Podem ser utilizados dois tipos de diagramas de interacção
Diagramas de Sequencia
Diagramas de Colaboração
Um diagrama de sequencia apresenta as interacções entre objectos organizadas numa sequencia temporal
: Estudante
formulário
Inscrição
gestor
inscrição
matemática
4: Funciona?
5: Funciona?
Um diagrama de colaboração apresenta as interacções entre objectos organizadas em torno dos objectos e das suas ligações
: Secretaria Académica
Formulario disciplina:
Diagramas de Classes
Um diagrama de Classes apresenta a existencia de classes e suas ligações segundo a visão lógica do sistema
Elementos de modelaçãoUML nos diagramas de class
Classes e a sua estrutura e comportamentos
Relações de associação, agregação, dependencia,e herança
Indicadores de multiplicidade e navigação
Nomes de “papeis”
Page *
R
Classes
Uma classe é uma coleção de objectos com uma estrutura e comportamento, relacionamentos e semantica comuns
Identificam-se classes examinando os objectos presentes nos diagramas de sequencia e de colaboração
Uma classe é desenhada como um rectangulo com três compartimentos
Classes devem ser designadas através de nomes utilizados no vocabulário do domínio.
Devem ser criadas normas de identificação
ex., todas as classes tem um nome singular que começa por maiuscula
Page *
R
Classes
FormInscricao
GestorInscricao
Disciplina
OfertaDisciplina
Professor
Estudante
AlgoritmoPlaneamento
Page *
R
Operações
O comportamento de uma classe é representado pelas suas operações
Operações são identificadas nos diagramas de interacção
formulario
inscrição
gestor
inscrição
GestorInscrição
A estructura de uma classe é representada pelos sues atributos
Podemos determinar os atributos examinando a definição das classes, os requisitos do problema e apliccando o nosso conhecimento do domínio
Cada oferta de disciplina
Os relacionamentos estabelecem um caminho para a comunicação entre objectos
Os diagramas de sequencia e/ou colaboração devem ser examinados de modo a determinar as ligações que devem existir entre objectos para concretizar o comportamento - deverá existir uma ligação entre dois objectos que precisam de “falar”.
O UML define três tipos de relacionamentos:
Associação
Agregação
Dependencia
Page *
R
Os relacionamentos identificam-se a partir dos diagramas de interacção
Se dois objectos necessitam de “falar” então deverá existir um caminho para a essa comunicação
3: adiciona estudante(jose)
Multiplicidade define quantos objectos participam no relacionamento
Multiplicidade representa o número de instancias de uma classe que estão relacionadas com UMA instancia de outra classe.
Para cada associação e agregação temos de decidir qual a multiplicidade em cada extremo do relacionamento.
Embora, por princípio, as associações e agregações sejam bi-direcionais é desejavel restringir a navegação a uma direcção previlegiada
Se a navegação for restringida, será incluida uma seta para indicar a direcção da navegação
Page *
R
Estudante
adicionaEstudante()
nome
numeroCreditos
abre()
adicionaEstudante(InfoEstudante)
nome
area
localização
abre()
adicionaEstudantet(InfoEstudante)
nome
categoriaAcademica
FormInscrição
GestorInscrição
Disciplina
OfertaDisciplina
Professor
AlgorimoPlaneamento
1
0..*
0..*
1
1
1..*
4
3..10
0..4
1
Page *
R
Herança
Herança é um relacionamento etre uma superclasse e as suas subclasses
Existem dois modos de identificar herança:
Generalização
Especialização
No nivel mais elevado da hierárquia apresentam-se atributos, operações e/ou relacionamentos comuns
Page *
R
Herança
FormInscrição
GestorInscricao
Disciplina
Estudante
OfertaDisciplina
Professor
adicionaEstudante()
nome
numeroCreditos
abre()
adicionaEstudante(InfoEstudante)
area
localização
abre()
adicionaEstudantet(StudentInfo)
categoriaAcademica
AlgoritmoPlaneamento
UtilizadorInscricao
nome
Page *
R
O diagrama de transição de estados apresenta
a história da vida de uma dada classe
os eventos que provocam a transição de um estado para outro
As acções que resultam de uma mudança de estado
Os diagrama de transição de estado são criados para objectos com um comportamento dinamico significativo
Page *
R
entry: Regista estudante
exit: Incrementa contador
Diagramas de componente ilustram a organização e dependencias entre componentes de software
Um componente pode ser
Um componente programa fonte
Um componente “run time”
Disciplina.dll
Pessoa.dll
Disciplina
OfertaDisciplina
Estudante
Professor
SecretariaAcademica.exe
Page *
R
Interfaces
Os interfaces de um componente devem ser apresentados no diagrama de componentes
Registo.exe
Contabilidade.exe
Contabilidade
Page *
R
O diagrama de implantação apresenta a configuração dos elementos de processamento (computadores) e dos processos de software que os utilizam
O diagrama de implantação descreve a localização dos componentes na empresa.
Page *
R
Estensão do UML
Os Estereotipos são um mecacnismo de classificação que permitem estender os elementos de notação do UML
Os Estereotipos podem ser utilizados para classificar e estender associações, relações de herança, classes e componentes
Exemplos:
Estereótipos de herança: “uses” e “extends”
Estereótipos de componente: subsistema
Estensão do UML
Um package é uma forma de organização de elementos de modelação. Cada pacote pode conter uma colecção de “use cases”, uma colecção de classes ou uma colecção de componentes.
As setas descrevem dependencias entre packages.
Exemplos
Pessoas: InfoEstudante, InfoProfessor
Package
Page *
R
Definir processos de negócio
Promover reutilização
O UML é uma linguagem “standard” para visualizar, especificar, construir e documentar os elementos de um sistema complexo de software.