Elsa Cardoso, DCTI - ISCTE

Transcrição

1 Elsa Cardoso, DCTI - ISCTE 25 Maio 2004 elsa.cardoso@iscte.pt

2 Sumário Perspectiva de Desenho do Sistema: Diagrama de classes numa perspectiva de Desenho: Estereótipos Relação de Dependência Relação de Realização Interfaces Conceitos UML Reutilização: 1. Interfaces para classes 2. Camadas (layers) no diagrama de classes 3. Pacotes Noção de Componente e Nó Diagramas de Componentes e de Instalação 2

3 Desenho do Sistema A fase de Desenho procura determinar COMO é que o sistema cumpre os requisitos - O diagrama de classes é refinado ao nível de Desenho REUTILIZAÇÃO Grande objectivo do desenvolvimento orientado por objectos, onde se procura produzir componentes reutilizáveis, que possam ser utilizados em diferentes aplicações, diminuindo os custos de desenvolvimento 3

4 Refinamento do Diagrama de Classes Conceitos UML 1. Estereótipo Mecanismo de extensibilidade que permite aumentar a flexibilidade das classes, através de uma subclassificação É possível criar novos estereótipos Os mais utilizados são: <<interface>> e <<control>> <<control>> ControloAc esso verificaacesso() <<Interface>> Gestão criar() apagar() ver() Classe com um conjunto de regras que controlam determinadas operações do sistema e que coordenam as interacções com as outras classes. ControloAcess o Gestão 4

5 Refinamento do Diagrama de Classes Conceitos UML 2. Noção de Dependência Utilizada quando uma classe recorre aos serviços disponibilizados por outra classe, numa relação de cliente/fornecedor de serviços Relação de Dependência Encomenda Funcionario bi nome morada Gestão numeroe data tipoencomenda criar() apagar() ver() A classe Funcionario depende (ou usa alguma funcionalidade) da classe Encomenda através da interface Gestão 5

6 Refinamento do Diagrama de Classes Conceitos UML 3. Noção de Realização Utilizada na modelação de um contrato entre uma classe que especifica o serviço e uma outra classe que garante a realização do serviço. Estabelece-se entre uma interface e uma classe ou entre uma interface e um componente. Mistura entre a relação de generalização e a de dependência (ver notação) Relação de Realização (forma expandida) Relação de Realização (forma simples) Funcionario bi nome morad a <<Interface>> Gestão Encomenda numeroe data ti poen comen da criar() apagar() ver() Funcionario bi nome morada Gestão Encomenda numeroe data tipoencomenda criar() apagar() ver() 6

7 Refinamento do Diagrama de Classes Conceitos UML 4. Interface Uma interface é um grupo de operações que são utilizadas para especificar um serviço. Este serviço funciona como um contrato entre a classe e os seus clientes Mecanismo para separação entre a vista externa e a vista interna de um determinado elemento usual nas linguagens de programação baseadas em objectos Uma interface é realizada (ou implementada) por uma ou mais classes, as quais prometem implementar todos os métodos nela especificados Conceito associado ao desenvolvimento de software baseado em componentes 7

8 Refinamento do Diagrama de Classes Conceitos UML 4. Interface benefícios ao nível da programação Captura de semelhanças entre classes não relacionadas sem forçar a criação de relações artificiais entre elas; Declaração de métodos que uma ou mais classes esperam implementar; Revelar a interface de programação de um objecto sem revelar a sua classe. I.e., um objecto pode ser visto de diferentes perspectivas (ou diferentes tipos) consoante as situações. 8

9 Refinamento do Diagrama de Classes Conceitos UML 4. Interface exemplo Funcionario bi nome morada Cliente bi : String nome : String mo rada : String pre Reg isto() <<Interface>> Gestão criar() apagar() ver() Encomenda numeroe : Long data : Date tipoencomenda : String valortotal : Long criar() apagar() ver() adicionaproduto() calculavalortotal() <<Interface>> Visualizar ver() Uma classe pode conter várias interfaces, fornecendo assim diferentes abstracções dos seus serviços, conforme o cliente. 9

10 Desenho do Sistema REUTILIZAÇÃO Algumas estratégias possíveis para, ao nível do Desenho, promover a reutilização: Interfaces para classes Camadas (layers) no diagrama de classes Pacotes 10

11 Camadas (layers) no Diagrama de Classes Reutilização Três camadas de serviços 1. Serviços de Interface ou User services fornece a interface do utilizador para apresentação e recolha de dados 2. Serviços de Negócio ou Business services engloba as classes que possuem as regras fundamentais do negócio 3. Serviços de Dados ou Data services permite manter, actualizar e aceder aos dados persistentes 11

12 Caso de Estudo: PhonePizza Ex. Diagrama de Classes com 3 níveis Serviços de Interface Serviços de Negócio Serviços de Dados <<user interface>> Ecrã Pré-registo <<user interface>> Ecrã Reservas <<user interface>> Ec rã Encomendas Controlo Acesso verificaacesso() Cliente {persistence=yes} bi nome morada pre-regist o() Enc omenda {pers ist ence=yes} numeroe data tipoencomenda criar() <<data connection>> SD_Cliente bi nome morada criar() apagar() consultar() actualizar() * <<data connection>> SD_Encomenda numeroe data tipoencomenda criar() apagar() consultar() actualizar() 1 efectua * 1 efectua 12

13 Pacotes organização de artefactos Reutilização Um pacote (package) em UML permite agrupar elementos de modelação (diagramas, classes, componentes, interfaces, etc) de um sistema de forma a que semântica ou estruturalmente faça sentido Gestão de Clientes Controlo de Acesso Vantagens: Gestão de Encomendas Encomendas Internet + FormEncomenda + FormCatalogo - Encomenda Gestão de Produt os (1) Facilita a gestão e procura de artefactos (2) Evita os conflitos de nomes (Ex: X::A é de Z::A) (3) Providencia um mecanismo de controlo de acessos (visibilidade) Pública: +, Privada: - e Protegida: # 13

14 Relações entre Pacotes Reutilização VISIBILIDADE Um elemento com Visibilidade Pública ( + ) pode ser usado/referenciado por qualquer outro elemento independentemente do local onde é definido Um elemento com Visibilidade Privada ( - ) pode ser usado/referenciado por elementos definidos no mesmo pacote Um elemento com Visibilidade Protegida ( # ) pode ser usado/referenciado por um elemento definido no mesmo pacote ou num outro pacote que seja uma especialização do primeiro Tipos de Relações entre Pacotes: Importação, Exportação e Generalização 14

15 Relações entre Pacotes Reutilização Relação de Exportação: Um pacote faz a exportação, por definição, de todos os seus elementos públicos. Isso não implica que um elemento definido noutro pacote possa aceder/referenciar um elemento exportado. Tem que existir explicitamente uma relação de importação entre os dois pacotes. Relação de Importação: É uma relação de dependência entre pacotes, especificando que o pacote base importa todos os elementos públicos definidos no pacote destino. Note-se que esta relação não é simétrica! Preferencialmente, os elementos exportados por cada pacote devem ser do tipo interface. 15

16 Relações entre Pacotes Reutilização Relação de Importação (exemplo) Gestão de Clientes Controlo de Acesso Gestão de Encomendas Gestão de Produtos 16

17 Relações entre Pacotes Reutilização Relação de Generalização: usada para a especificação de famílias ou hierarquias de pacotes, típicas em sistemas complexo (máximo 3 níveis!...) Gestão de Encomendas Encomendas Internet Encomendas Central Encomendas Telefone Encomendas Pizzaria HIERARQUIA DE PACOTES 17

18 Noção de Componente Noção Geral: Uma componente é uma entidade que possa ser reutilizada. [Silva2001] Exemplos: Conjunto de classes C++ (implementação) Conjunto de use cases (nível especificação de requisitos) Conjunto de diagramas de classes (nível de análise ou de desenho) Desde que tenham sido definidos de forma a serem reutilizáveis!... Definição [Silva, 2001] Uma componente é uma peça básica na implementação de um sistema. Consiste num conjunto de artefactos físicos em formato digital, como por exemplo: - ficheiros de código (fonte, binário ou executáveis) - ficheiros de documentos relativos ao negócio. 18

19 Noção de Componente Definição de Componente: [SCREEN, 1996] A component is any object or collection of objects that is a unit of construction and reuse. It has a purpose of existence, certain behaviour, interacts with the external world, and can be controlled. Definição [Nunes, 2003] Uma componente de software representa um módulo físico de código. Definição de Componente de Software: [Schmuller, 1999] A software component is a physical part of a system. It resides in a computer, not in the mind of the analyst. Examples: table, data files, executable, dynamic link library, document,... 19

20 Diagrama de Componentes Objectivo Os diagramas de Componentes utilizam-se para modelar a arquitectura de um sistema de software na perspectiva dos seus componentes digitais, explicitando as relações de dependência entre as várias componentes de software. Um diagrama de componentes representa apenas tipos de componentes, NUNCA instâncias de componentes. As instâncias de componentes devem ser representadas num diagrama de Instalação Controlo Acesso 20

21 Componentes e Classes Uma componente é uma implementação em software de uma classe. Uma classe representa uma abstracção de um conjunto de atributos e operações. Uma componente pode ser a implementação de várias classes. 21

22 Componentes e Interfaces Uma interface é um conjunto de operações que uma classe apresenta às outras classes. A interface que uma classe usa é a mesma interface que a respectiva implementação de software (a componente) usa. Em UML não há distinção de interfaces conceptuais e físicas. <<DLL>> ControloAcesso Internet 22

23 Tipos de Componentes Três Tipos de Componentes: Instalação, Trabalho e Execução Componentes de Instalação (Deployment Components): constituem a base dos sistemas executáveis (e.g., DLL, executáveis, classes Java) Componentes de Trabalho (Work Product Components): a partir dos quais são criados os componentes de instalação (e.g., ficheiros com código fonte, ficheiros de dados, documentos) Componentes de Execução (Execution Components): criados como resultado da execução de um sistema (e.g., processos, threads, agentes de software) apenas representadas nos Diagramas de Instalação (Deployment diagrams). 23

24 Estereótipos para Componentes <<document>> denota um documento <<executable>> denota um programa que possa ser executado num nó <<file>> denota um documento que contém código fonte ou dados <<library>> denota uma biblioteca dinâmica ou estática <<table>> denota uma tabela de uma base de dados 24

25 Diagrama de Componentes Um exemplo Considere a aplicação WinCOR desenvolvida sobre MS-Windows responsável pela gestão (entrada e saída) da correspondência de uma empresa. A aplicação consiste no seguinte conjunto de componentes de instalação (deployment components): wincor.exe ficheiro com o executável da aplicação pblib32.dll, sde32.dll, sdemdb32.dll bibliotecas com código binário com funcionalidades adicionais wincor.hlp ficheiro de ajuda da aplicação wincor.ini ficheiro de configuração da aplicação entrada.db, saida.db ficheiros/tabelas da base de dados de suporte Desenhe o Diagrama de Componentes desta aplicação, tendo em atenção que (1) o executável só pode correr se todos os restantes componentes tiverem sido instalados; e (2) o módulo sdemdb32.dll depende do módulo sde32.dll. 25

26 Diagrama de Componentes Um exemplo <<document>> wincor.hlp <<library>> pblib.dll <<document>> winc or.ini <<executable>> wincor.exe <<table>> entrada.db <<table>> saida.db <<library>> sde32.dll <<library>> sdem32db.dll 26

27 Noção de Nó Um nó é um objecto físico que representa um recurso de processamento. Os nós podem consistir em recursos computacionais (hardware), e recursos de processamento mecânico. Os nós podem ser representados como tipos e como instâncias. Instâncias de nós podem conter instâncias de objectos e de componentes. Nó (instância de nó) <<processor>> lisboa004: Kiosk <<device>> Monit or Nó (tipo de nó) 27

28 Noção de Nó Dois nós podem estar ligados através de relações de associação, que especificam a existência de caminhos de comunicação entre eles. As comunicações podem ser caracterizadas por um estereótipo, indicando o tipo de comunicação envolvido (e.g., o tipo de canal ou o tipo de rede). As propriedades dos nós são representadas por marcas com valores. Podem também ser definidos ícones para modelar diferentes tipos de recursos de processamento. Os nós podem ser classificados através de estereótipos, para representar com mais detalhe os recursos físicos: <<processor>> denota um nó que pode executar uma componente de software <<device>> denota um nó que não tem capacidade para executar componentes de software; e.g., uma impressora, um scanner, ou um monitor. 28

29 Diagrama de Instalação* (Deployment Diagram) * Também denominados Diagramas de Distribuição Objectivo Os diagramas de Instalação utilizam-se para descrever a arquitectura de um sistema de software em termos de hardware e a sua relação com os diferentes componentes (software) As componentes têm que ser executadas em algum recurso computacional que contenha memória e um processador. O Diagrama de Instalação define em que recursos os diferentes componentes estarão localizados e processados Servidor http Servidor Encomendas Cent ral Nó (tipo de nó) TCP/IP - XML Comunicação 29

30 Referências UML Metodologias e Ferramentas CASE Alberto Silva, Carlos Videira, Edições Centro Atlântico, Fundamental de UML, 2ª ed. Mauro Nunes, Henrique O Neill, FCA, 2003 UML in 24 Hours. Joseph Schuller, SAMS Macmillan Computer Publishing, 1999