University Registration System for Academic Management

1. Sistema de Inscrições • A 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.

2. Secretaria Académica Contabilidade Estudante Professor Actores • Um actor é alguém ou algo que tem de interagir com o sistema que está a ser desenvolvido

3. Solicitar Lista Candidatos Fazer inscrição Manter Curriculum 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 • Contabilidade -- receber a informação contabilística da Secretaria Académica

4. Fluxo de Eventos 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.

5. Solicitar Lista de Candidatos Inscrever em Disciplina Secretaria Académica Contabilidade Estudante Professor Manter Curriculum Diagrama de “Use Case” • Os diagramas de “Use case” são criados para visualizar as relações entre os actores e os “use cases”

6. 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

7. formulário gestor matemática matemática : Estudante estatística Inscrição inscrição 1: preenche info 2: submete 3: adiciona disciplina (jose, matematica, estatística) 4: Funciona? 5: Funciona? 6: adiciona (jose) 7: adiciona (jose) Diagrama de Sequencia • Um diagrama de sequencia apresenta as interacções entre objectos organizadas numa sequencia temporal

8. Formulario disciplina: FormularioDisciplina 1: define informação disciplina 2: processa 3: adiciona disciplina : Secretaria Académica oGestor : umaDisciplina : gestorCurriculum Disciplina 4: nova disciplina Diagrama de Colaboração • Um diagrama de colaboração apresenta as interacções entre objectos organizadas em torno dos objectos e das suas ligações

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

10. 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

11. AlgoritmoPlaneamento FormInscricao GestorInscricao Disciplina Estudante Professor OfertaDisciplina Classes

12. formulario gestor inscrição inscrição GestorInscrição 3: adicionar disciplina (jose, matematica, estatistica) adicionarDisciplina (Estudante, Area,Disciplina) Operações • O comportamento de uma classe é representado pelas suas operações • Operações são identificadas nos diagramas de interacção

13. OfertaDisciplina numero localização hora Atributos • 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 possui um número, localização e hora

14. AlgoritmoPlaneamento FormInscrição GestorInscrição adicionarEstudante(Disciplina, InfoEstudante) nome Disciplina numeroCreditos open() nome addStudent(StudentInfo) Estudante área nome Professor categoriaAcademica localização OfertaDisciplina abri() AdicionarEstudante (InfoEstudante) Classes

15. Relacionamentos • 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

16. Gestor Matematica: Inscrição Disciplina 3: adiciona estudante(jose) GestorInscrição Disciplina Procurar Relacionamentos • 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

17. AlgoritmoPlaneamento FormInscrição Disciplina Estudante Professor OfertaDisciplina Relacionamentos GestorInscrição adicionaEstudante(Disciplina, InfoEstudante) nome numeroCreditos abre() nome adicionaEstudante(InforEstudante) área nome categoriaAcademica localização abre() adicionaEstudante(InfoEstudant)

18. Multiplicidade e Navigação • 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

19. AlgorimoPlaneamento FormInscrição 0..* 1 GestorInscrição 1 0..* Disciplina 1 3..10 1..* 4 Professor 1 OfertaDisciplina 0..4 Multiplicidade e Navigação adicionaEstudante() nome numeroCreditos Estudante abre() adicionaEstudante(InfoEstudante) nome area nome categoriaAcademica localização abre() adicionaEstudantet(InfoEstudante)

20. 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

21. AlgoritmoPlaneamento FormInscrição GestorInscricao adicionaEstudante() UtilizadorInscricao Disciplina nome nome numeroCreditos Estudante abre() adicionaEstudante(InfoEstudante) area Professor OfertaDisciplina categoriaAcademica localização abre() adicionaEstudantet(StudentInfo) Herança

22. O Estado de um Objecto • 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

23. Adiciona estudante[ contador < 10 ] Adiciona Estudante / Set contador = 0 Iniciado Aberto do: Inicia disciplina Cancela Cancela [ contador = 10 ] Cancelado do: Notifica estudantes inscritos Encerrado Cancela do: Finaliza disciplina Diagrama de Transição de Estado entry: Regista estudante exit: Incrementa contador

24. O Mundo Físico: Implementação • 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” • Um componente executavel

25. SecretariaAcademica.exe Pessoa.dll Disciplina.dll Disciplina Professor Estudante OfertaDisciplina Diagrama de Componentes

26. Interfaces • Os interfaces de um componente devem ser apresentados no diagrama de componentes Registo.exe Contabilidade.exe Contabilidade

27. Implantação do Sistema • 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.

28. Secretaria Académica Base de dados Edíficio Biblioteca Principal Sala Convívio Diagrama de Implantação

29. 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 classe : fronteira, controlo, entidade, utilidade, excepção, interface • Estereótipos de herança: “uses” e “extends” • Estereótipos de componente: subsistema “Control” GestorInscrição “Excepção” Inscrição Recusada

30. Package 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 • Interfaces: FormInscrição, FormSelacçaoDisciplina, ... • Elementos da Universidade: Disciplina, OfertaDisciplina, ListaCandidatos • Pessoas: InfoEstudante, InfoProfessor • Base de Dados: repositório de dados

31. Elementos Universidade Base de dados Interfaces Pessoas Estensão do UML • Packages

32. Conclusões • Modelação visual pode ser utilizada para: • Definir processos de negócio • Comunicar • Dominar complexidade • Definir arquitectura de software • Promover reutilização • O UML é uma linguagem “standard” para visualizar, especificar, construir e documentar os elementos de um sistema complexo de software. • O UML pode sre utilizado com todos os processos, ao longo de todo o ciclo de desenvolvimento e utilizando diversas tecnologias de implementação.