Processo Unificado

1. Processo Unificado Marcio de Carvalho Victorino mcvictorino@uol.com.br

2. Unidade V: Projeto OO (Aspectos Estáticos)

3. Introdução • Em sistemas OO, a mesma representação é utilizada durante a análise e o projeto. • Vantagem: há uma uniformidade na modelagem do sistema. • Desvantagem: torna menos nítida a separação entre o que é feito na análise e o que é feito no projeto.

4. Introdução • É na fase de projeto de uma iteração que essas definições são feitas. • As atividades realizadas na fase de projeto são as seguintes: 1. Detalhamento dos aspectos dinâmicos do sistema. 2. Refinamento dos aspectos estáticos e estruturais do sistema. 3. Definição de outros aspectos da solução. • Após essas atividades, os modelos estão em um nível de detalhamento suficiente para serem implementados.

5. Transformação de Classes de Domínios em Classes de Especificação • O modelo de classes de especificação é resultante de refinamentos no modelo de classes de domínio. • Após sua construção, o modelo de especificação é passado aos programadores para que eles o implementem.

6. Especificação de Classes de Fronteira • Durante a análise, considera-se que há uma única classe de fronteira para cada ator. • Na passagem para o modelo de especificação, algumas dessas classes podem resultar em várias outras. • Interface como seres humanos: projeto da interface gráfica produz o detalhamento das classes. • Equipamentos: uma ou mais classes para encapsular o protocolo de comunicação do equipamento. • O mesmo vale para comunicação com outros sistemas.

7. Especificação de Classes de Entidade • Normalmente precisam de armazenamento persistente. • As classes de entidades que devem ser armazenadas de modo persistente devem ser identificadas na especificação. • Também devem ser identificados os padrões de acesso a cada classe de entidade cujos objetos devem ser persistentes. • A taxa de acesso a uma coleção influencia na política de armazenamento.

8. Especificação de Classes de Controle • Na especificação, deve-se analisar a verdadeira utilidade de cada classe de controle identificada durante a análise. • Em casos de uso simples (manutenção de dados), classes de controle não são realmente necessárias. • classes de fronteira podem repassar os dados fornecidos pelos atores diretamente para as classes de entidade correspondentes. • Em casos de uso complexos, uma classe de controle de análise pode resultar em duas ou mais classes de especificação.

9. Especificação de Atributos • A especificação completa de um atributo deve seguir a sintaxe: visibilidade nome: tipo = valor-inicial • Visibilidade e encapsulamento. • Tipo pode ser um TAD. • Tipo e valor inicial dependentes de linguagem. • Atributo derivado • Escopo do atributo

10. Especificação de Atributos • Público (+) • Package (~) • Protegido (#) • Privado (-)

11. Especificação de Operações • Operação: um processamento realizado por (um objeto de) uma classe. • Em termos de implementação: é uma rotina (método) associada a uma classe. • Na construção do modelo de interações, operações identificadas na análise são validadas e várias outras operações são identificadas. • Essas operações devem ser adicionadas ao diagrama de classes e documentadas através da definição de sua assinatura.

12. Especificação de Operações visibilidade nome(parâmetros): tipo-retorno Onde, para cada parâmetro: nome-parâmetro: tipo-parâmetro • Visibilidade e encapsulamento. • Tipo pode ser um TAD. • Tipo de retorno e dos parâmetros dependentes de linguagem. • Escopo da operação

13. Especificação de Operações

14. Relacionamento de Dependência • Na UML, há três tipos de relacionamentos entre objetos: • Associações • Generalizações • Dependências • No modelo de classes de domínio, os relacionamentos entre objetos são identificados como associações.

15. Navegabilidade de Associações • Associações, agregações e composições podem ser bidirecionais e unidirecionais. • Uma associação bidirecional indica que há um conhecimento mútuo entre os objetos associados. • Na UML, associações são, por omissão, navegáveis em ambos os sentidos. • Uma associação unidirecional é representada adicionando-se um sentido à seta da associação.

16. Navegabilidade de Associações

17. Navegabilidade de Associações • No modelo de classes de especificação, a navegabilidade de todas as associações deve ser definida. • Algumas associações permanecem bidirecionais. • Se não houver essa necessidade, recomenda-se transformar a associação em unidirecional. • A escolha do sentido da navegabilidade pode ser feita através dos diagramas de interação. • Mensagens influenciam na existência ou não de navegabilidade em um sentido.

18. Implementação de Associações • Para associações de conectividade um para um, a implementação é trivial: é definido um atributo do tipo Cb na classe Ca. • Navegabilidade bidirecional: aplica-se o procedimento acima para as duas classes. • Portanto, em associações um para um, não há necessidade de um refinamento adicional do diagrama de classes.

19. Implementação de Associações • Em associações de conectividade um para muitos ou muitos para muitos, detalhes adicionais podem ser representados para esclarecer como implementar tais associações. • O detalhamento de associações se baseia em classes que representam coleções de elementos.

20. Generalização • Também pode ser chamado de relacionamento de especialização, pois a generalização e a especialização são dois pontos de vista do mesmo relacionamento. • O termo herança também é comumente utilizado como sinônimo do relacionamento de generalização. (implementação) • A generalização pode ser utilizada tanto no modelo de classes de domínio quanto no de especificação.

21. Generalização

22. Generalização X Associação • Importante: a generalização difere da associação (agregação, composição ) porque a primeira se trata de um relacionamento entre classes. • “Gerentes são tipos especiais de funcionários”. • “Gerentes chefiam departamentos”. • Na associação, objetos específicos de uma classe se associam entre si ou com objetos específicos de outras classes.

23. Herança de Associações • Atributos e operações e associações são herdados pelas subclasses.

24. Hierarquias de Generalização • A generalização pode ser aplicada em vários níveis (hierarquia de generalização). • uma classe que herda propriedades de uma outra classe pode ela própria servir como superclasse. • Características importantes: • Transitividade: uma classe em uma hierarquia herda propriedades e relacionamentos de todos os seus ancestrais. • Assimetria: dadas duas classes A e B, se A for uma generalização de B, então B não pode ser uma generalização de A. Ou seja, não pode haver ciclos em uma hierarquia de generalização.

25. Herança Múltipla • Herança múltipla: Uma classe pode ter mais de uma superclasse. • Tal classe herda de todas a suas superclasses. • O uso de herança múltipla deve ser evitado. • Esse tipo de herança é difícil de entender. • Algumas LPs não dão suporte à implementação desse tipo de herança (Java e Smalltalk).

26. Classes Abstratas • Usualmente, a existência de uma classe se justifica pelo fato de haver a possibilidade de gerar instâncias (classes concretas). • No entanto, podem existir classes que não geram instâncias diretas: classes abstratas. • Utilizadas para organizar e simplificar uma hierarquia de generalização. • Propriedades comuns a diversas classes podem ser organizadas e definidas em uma classe abstrata a partir da qual as primeiras herdam. • Subclasses de uma classe abstrata também podem ser abstratas, mas a hierarquia deve terminar em uma ou mais classes concretas.

27. Classes Abstratas

28. Arquitetura em Camadas • Uma forma de organizar a arquitetura de um sistema complexo em partes menores é através de camadas de software. • Uma camada de software, é uma coleção de subsistemas. • Cada camada corresponde a um conjunto de funcionalidades de um sistema de software. • Funcionalidades de alto nível dependem de funcionalidades de baixo nível. • Camadas fornecem um nível de abstração através do agrupamento lógico de subsistemas relacionados.

29. Arquitetura em Camadas • Princípio geral: camadas de abstração mais alta devem depender das camadas de abstração mais baixa, e não o contrário. • Permite que o sistema de software seja mais portável e modificável. • Uma mudança em uma camada mais baixa que não afete a sua interface não implicará em mudanças nas camadas mais altas. • E vice-versa, uma mudança em uma camada mais alta que não implica na criação de um novo serviço em uma camada mais baixa não irá afetar estas últimas.

30. Arquitetura em Camadas • A UML não tem nenhum elemento gráfico pré-específico para representar camadas de um sistema. • No entanto, pacotes também podem ser utilizados para representar camadas. • O estereótipo <<camada>> pode ser utilizado no pacote que represente uma camada. • O fato de uma camada utilizar outra pode ser representado por um relacionamento de dependência.

31. Sistema Cliente-Servidor • Um sistema cliente-servidor clássico é dividido em duas camadas. A primeira (cliente) requisita serviços à segunda (servidor). • O cliente é normalmente responsável pela interface gráfica com o usuário. • O servidor é normalmente pode servir a diversos clientes para fornecer diversos serviços (segurança, impressão, correio eletrônico, gerenciamento de janelas, etc.).

32. Sistema Cliente-Servidor • Sistemas cliente-servidor em duas camadas foram dominantes durante aproximadamente toda a década de 90 e são utilizados até hoje. • A construção de sistemas cliente-servidor é vantajosa quando o número de clientes não é tão grande • por exemplo, uma centena de clientes interagindo com o servidor através de uma rede local.

33. Sistema Cliente-Servidor • No entanto, com o surgimento da Internet. Rapidamente, originou-se uma demanda pela construção de sistemas de software que pudessem ser utilizados nesse ambiente. • Isto causou problemas em relação à estratégia cliente-servidor de duas camadas, principalmente em relação à construção de clientes gordos. • Internet: permitir o acesso a variados recursos através de um programa navegador (browser), que não fornece grande suporte à construção daquele tipo de cliente.

34. Sistema em três Camadas • Solução encontrada: adição de um nova camada de software. • Sistemas construídos segundo essa estratégia são denominados sistemas cliente-servidor em três camadas. • Essas camadas normalmente recebem os seguintes nomes: • camada de apresentação • camada da lógica do negócio • camada de acesso

35. Camada Apresentação • Classes que contêm funcionalidade para visualização dos dados pelos usuários. • As classes de fronteira para atores humanos se encontram nessa camada. • Objetivo: exibir informações ao usuário e traduzir ações do usuário em requisições às demais partes do sistema. • Exemplos de camadas de apresentação: • um sistema de menus baseados em texto; • uma página escrita em HTML ou XHTML com JavaScript apresentada em um navegador de Internet; • uma interface gráfica construída em algum ambiente de programação visual.

36. Camada da Lógica do Negócio • Consiste da camada existente no servidor de aplicação. • Classes que implementam as regras do negócio no qual o sistema está para ser implantado. • Além disso, essa camada deve decidir que parte da camada de acesso de ser ativada com base em requisições provenientes da camada de apresentação. • Nessa camada, são realizadas computações com base nos dados armazenados ou nos dados de entrada.

37. Camada de Acesso • Contém classes que se comunicam com outros sistemas para realizar tarefas ou adquirir informações para o sistema. • Tipicamente essa camada é implementada utilizando algum mecanismo de armazenamento persistente (SGBD). • Pode haver uma subcamada dentro desta camada: a camada de persistência • isola o restante do sistema de modificações no mecanismo de armazenamento persistente.

38. Arquitetura Física • Representa a disposição física do sistema de software pelo hardware disponível. • A divisão de um sistema em camadas é independente da sua disposição física. • As camadas de software podem estar fisicamente localizadas em uma única máquina, ou podem estar distribuídas por diversos processadores. • Alternativamente, essas camadas podem estar distribuídas fisicamente em vários processadores. (Por exemplo, quando a camada da lógica do negócio é dividida em duas ou mais máquinas.)

39. Arquitetura Física • O modelo que representa a arquitetura física é denominado modelo de implantação ou modelo da arquitetura física. • Há dois tipos de diagramas na UML utilizados para modelar a arquitetura física: • diagrama de implantação • diagrama de componentes

40. Componente Interface Dependência Diagrama de Componentes • Mostra os vários componentes de software de um sistema, além das dependências entre estes últimos. • Os elementos gráficos desse diagrama:

41. Diagrama de Componentes

42. Diagrama de Componentes • A UML define diversos estereótipos para componentes: • <<executável>>: um componente que pode ser executado. • <<documento>>: um documento. Por exemplo, um manual de instalação ou um manual do usuário. • <<tabela>>: uma tabela em um banco de dados. • <<arquivo>>: um arquivo de dados. • <<biblioteca>>: uma biblioteca de objetos ou de funções. Por exemplo, uma DLL.

43. Diagrama de Implantação • Representa a topologia física do sistema e opcionalmente os componentes que são executados nesta topologia. • Apresenta um mapeamento entre os componentes de software e o hardware utilizado. • Elementos: nós e conexões. • Um nó é uma unidade física que representa um recurso computacional. • Normalmente possui uma memória e alguma capacidade de processamento. • Exemplos: processadores, dispositivos, sensores, roteadores ou qualquer equipamento de importância para o sistema de software.

44. Diagrama de Implantação • Os nós são conectados uns aos outros através das conexões. • Conexões mostram mecanismos de comunicação entre os nós. • Meios físicos (cabo coaxial, fibra ótica, etc.) ou protocolos de comunicação (TCP/IP, HTTP, etc.). • Um nó é representado através de um cubo. • Nome e tipo do nó definidos no interior do cubo. • A sintaxe para o nome e o tipo do nó é similar à utilizada para os diagramas de objetos. • Tanto o nome quanto o tipo são opcionais. • Uma conexão é representada graficamente por uma linha (estereotipada) ligando dois nós.

45. <<HTTP>> <<ODBC>> <<LAN>> cliente:Browser :Impressora Servidor de Aplicação BD Corporativo Diagrama de Implantação

46. FIM