Modelagem de Sistemas de Software Orientados a Objetos

Sistemas de Informações

• A necessidade é a mãe das invenções.
• Em consequência do crescimento da importância da informação, surgiu a necessidade de gerenciar informações de uma forma adequada e eficiente e, desta necessidade, surgiram os denominados sistemas de informações.
• Um SI é uma combinação de pessoas, dados, processos, interfaces, redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização com relação às informações.
  • Vantagens do ponto de vista competitivo.
• Objetivo principal e final da construção de um SI: adição de valor à organização.

Sistemas de Software

• Um dos componentes de um SI é denominado sistema de software.
• Compreende os módulos funcionais computadorizados que interagem entre si para proporcionar a automatização de diversas tarefas.
• Característica intrínseca do desenvolvimento de sistemas de software: complexidade.

Modelos de Software

• Na construção de sistemas de software, assim como na construção de sistemas habitacionais, também há uma gradação de complexidade.
  • A construção desses sistemas necessita de um planejamento inicial.
• Um modelo pode ser visto como uma representação idealizada de um sistema que se planeja construir.
• Maquetes de edifícios e de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos.

Razões para Construção de Modelos

A princípio, podemos ver a construção de modelos como uma atividade que atrasa o desenvolvimento do software propriamente dito.

• Mas essa atividade propicia...
  • O gerenciamento da complexidade inerente ao desenvolvimento de software.
  • A comunicação entre as pessoas envolvidas.
  • A redução dos custos no desenvolvimento.
  • A predição do comportamento futuro do sistema.
• Entretanto, note o fator complexidade como condicionante dessas vantagens.

Diagramas e Documentação

No contexto de desenvolvimento de software, correspondem a desenhos gráficos que seguem algum padrão lógico.

• Podemos também dizer que um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem um significado predefinido.
• Diagramas normalmente são construídos de acordo com regras de notação bem definidas.
  • Ou seja, cada forma gráfica utilizada em um diagrama de modelagem tem um significado específico.

Diagramas permitem a construção de uma representação concisa de um sistema a ser construído.

• “uma figura vale por mil palavras”
• No entanto, modelos também são compostos de informações textuais.
• Dado um modelo de uma das perspectivas de um sistema, diz-se que o seu diagrama, juntamente com a informação textual associada, formam a documentação deste modelo.

Modelagem de Software

A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares.

Modelagem Visual significa modelar com a utilização de notações padrões.

A Modelagem Visual promove a Reutilização.

Paradigma

• Um paradigma é uma forma de abordar um problema.
• No contexto da modelagem de um sistema de software, um paradigma tem a ver com a forma pela qual esse sistema é entendido e construído.
• A primeira abordagem usada para modelagem de sistemas de software foi o paradigma estruturado.
  • Uso da técnica de decomposição funcional –“divida sucessivamente um problema complexo em subproblemas”
• Hoje em dia, praticamente suplantou o paradigma anterior, o paradigma da orientação a objetos...

Analogia Biológica

• Cada “célula” interagiria com outras células através do envio de mensagens para realizar um objetivo comum.
• Adicionalmente, cada célula se comportaria como uma unidade autônoma.
• De uma forma mais geral, Kay pensou em como construir um sistema de software a partir de agentes autônomos que interagem entre si.

Fundamentos da Orientação a Objetos

• Através de sua analogia biológica, Alan Kay definiu os fundamentos da orientação a objetos.

  1. Qualquer coisa é um objeto.
  2. Objetos realizam tarefas através da requisição de serviços a outros objetos.
  3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares.
  4. A classe é um repositório para comportamento associado ao objeto.
  5. Classes são organizadas em hierarquias.

O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados objetos. Cada objeto é responsável por realizar tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada.

Um sistema de software orientado a objetos consiste de objetos em colaboração com o objetivo de realizar as funcionalidades deste sistema. Cada objeto é responsável por tarefas específicas. É através da cooperação entre objetos que a computação do sistema se desenvolve.

Conceitos e Princípios da OO

• Conceitos
  • Classe
  • Objeto
  • Mensagem
• Princípios
  • Encapsulamento
  • Polimorfismo
  • Generalização (Herança)
  • Composição

Classes, Objetos e Mensagens

• O mundo real é formado de coisas.
• Na terminologia de orientação a objetos, estas coisas do mundo real são denominadas objetos.
• Seres humanos costumam agrupar os objetos para entendê-los.
• A descrição de um grupo de objetos é denominada classe de objetos, ou simplesmente de classe.

O que é uma Classe?

• Uma classe é um molde para objetos. Diz-se que um objeto é uma instância de uma classe.
• Uma classe é uma abstração das características relevantes de um grupo de coisas do mundo real.
  • Na maioria das vezes, um grupo de objetos do mundo real é muito complexo para que todas as suas características e comportamento sejam representados em uma classe.

Abstração

• Uma abstração é qualquer modelo que inclui os aspectos relevantes de alguma coisa, ao mesmo tempo em que ignora os menos importantes. A abstração depende do observador.

Abstração na Orientação a Objetos

• A orientação a objetos faz uso intenso de abstrações.
  • Os princípios da OO podem ser vistos como aplicações da abstração.
• Princípios da OO: encapsulamento, polimorfismo, herança e composição.

Objetos como Abstrações

• Uma abstração é uma representação das características e do comportamento relevantes de um conceito do mundo real para um determinado problema.
• Dependendo do contexto, um mesmo conceito do mundo real pode ser representado por diferentes abstrações.
  • Carro (para uma transportadora de cargas)
  • Carro (para uma fábrica de automóveis)
  • Carro (para um colecionador)
  • Carro (para uma empresa de kart)
  • Carro (para um mecânico)

Classe X Objeto

• Objetos são abstrações de entidades que existem no mundo real.
• Classes são definições estáticas, que possibilitam o entendimento de um grupo de objetos.
• CUIDADO: estes dois termos muitas vezes são usados indistintamente em textos sobre orientação a objetos.

Mensagens

• Para que um objeto realize alguma tarefa, deve haver um estímulo enviado a este objeto.
• Pense em um objeto como uma entidade ativa que representa uma abstração de algo do mundo real
  • Então faz sentido dizer que tal objeto pode responder a estímulos a ele enviados
  • Assim como faz sentido dizer que seres vivos reagem a estímulos que eles recebem.
• Independentemente da origem do estímulo, quando ele ocorre, diz-se que o objeto em questão está recebendo uma mensagem.
• Uma mensagem é uma requisição enviada de um objeto a outro para que este último realize alguma operação. Objetos de um sistema trocam mensagens –isto significa que estes objetos estão enviando mensagens uns aos outros com o objetivo de realizar alguma tarefa dentro do sistema no qual eles estão inseridos.

Encapsulamento

• Objetos possuem comportamento.
  • O termo comportamento diz respeito a que operações são realizadas por um objeto e também de que modo estas operações são executadas.
• De acordo com o encapsulamento, objetos devem “esconder” a sua complexidade...
• Esse princípio aumenta qualidade do SSOO, em termos de:
  • Legibilidade
  • Clareza
  • Reuso

O encapsulamento é uma forma de restringir o acesso ao comportamento interno de um objeto.

• Um objeto que precise da colaboração de outro para realizar alguma tarefa simplesmente envia uma mensagem a este último.
• O método (maneira de fazer) que o objeto requisitado usa para realizar a tarefa não é conhecido dos objetos requisitantes.
• Na terminologia da orientação a objetos, diz-se que um objeto possui uma interface.
  • A interface de um objeto é o que ele conhece e o que ele sabe fazer, sem descrever como o objeto conhece ou faz.
  • A interface de um objeto define os serviços que ele pode realizar e consequentemente as mensagens que ele recebe.

Uma interface pode ter várias formas de implementação.

• Mas, pelo princípio do encapsulamento, a implementação utilizada por um objeto receptor de uma mensagem não importa para um objeto remetente da mesma.

Generalização (Herança)

• A herança pode ser vista como um nível de abstração acima da encontrada entre classes e objetos.
• Na herança, classes semelhantes são agrupadas em hierarquias.
  • Cada nível de uma hierarquia pode ser visto como um nível de abstração.
  • Cada classe em um nível da hierarquia herda as características das classes nos níveis acima.

A herança facilita o compartilhamento de comportamento entre classes semelhantes.

• As diferenças ou variações de uma classe em particular podem ser organizadas de forma mais clara.

Superclasses representam abstrações generalizadas e subclasses representam especializações, onde atributos e métodos específicos são adicionados, modificados ou removidos.

Herança Múltipla

Permite que uma classe tenha mais que uma superclasse associada e que herde características de todas elas.

Polimorfismo

É a habilidade de objetos de classes diferentes responderem a mesma mensagem de diferentes maneiras.

• Em uma linguagem orientada a objetos:

for(i = 0; i < poligonos.tamanho(); i++)
    poligonos[i].desenhar();

Evolução Histórica da Modelagem de Sistemas

A Linguagem de Modelagem Unificada

Evolução do Software

• O rápido crescimento da capacidade computacional das máquinas resultou na demanda por sistemas de software cada vez mais complexos.
• O surgimento de sistemas de software mais complexos resultou na necessidade de reavaliação da forma de se desenvolver sistemas.
• Consequentemente as técnicas utilizadas para a construção de sistemas computacionais têm evoluído de forma impressionante, notavelmente no que tange à modelagem de sistemas.
• Na primeira metade da década de 90 surgiram várias propostas de técnicas para modelagem de sistemas segundo o paradigma orientado a objetos.
• Houve uma grande proliferação de propostas para modelagem orientada a objetos.
  • diferentes notações gráficas para modelar uma mesma perspectiva de um sistema.
  • cada técnica tinha seus pontos fortes e fracos.

Necessidade de um Padrão

• Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente.
• Alguns esforços nesse sentido de padronização, o principal liderado pelo “três amigos”.
• Surge a UML (Unified Modeling Language) em 1996 como a melhor candidata para ser linguagem “unificadora”.
• Em 1997, a UML é aprovada como padrão pelo OMG.
• Desde então, a UML tem tido grande aceitação pela comunidade de desenvolvedores de sistemas.
• É uma linguagem ainda em desenvolvimento.
• Atualmente na versão 2.0.

UML (Linguagem de Modelagem Unificada)

• “A UML é a linguagem padrão para visualizar, especificar, construir e documentar os artefatos de software de um sistema.”
• Unificação de diversas notações anteriores.
• Mentores: Booch, Rumbaugh e Jacobson –“Três Amigos” –IBM Rational (www.rational.com)

UML (Linguagem de Modelagem Unificada)

• UML é...
  • uma linguagem visual.
  • independente de linguagem de programação.
  • independente de processo de desenvolvimento.
• UML não é...
  • uma linguagem programação (mas possui versões!).
  • uma técnica de modelagem.
• Um processo de desenvolvimento que utilize a UML como linguagem de modelagem envolve a criação de diversos documentos.
  • Estes documentos, denominados artefatos de software, podem ser textuais ou gráficos.
• Os artefatos gráficos produzidos de um sistema OO são definidos através dos diagramas da UML.

Um diagrama na UML é uma apresentação de uma coleção de elementos gráficos que possuem um significado predefinido.

• No contexto de desenvolvimento de software, correspondem a desenhos gráficos que seguem algum padrão lógico.
• Um processo de desenvolvimento que utilize a UML como linguagem de modelagem envolve a criação de diversos documentos.
  • Estes documentos, denominados artefatos de software, podem ser textuais ou gráficos.
• Os artefatos gráficos produzidos no desenvolvimento de um SSOO são definidos através dos diagramas da UML.

Requisitos Funcionais

• São as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. - Prof. Tavares
• Descrevem o que o sistema deve fazer.
• Inicialmente, a especificação de requisitos funcionais deve ser completa e consistente. Completeza significa que todas as funções requeridas pelo usuário devem estar definidas.
• Consistência significa que os requisitos não devem ter - Prof. Tavares definições contraditórias.

Requisitos Não Funcionais

São restrições sobre os serviços ou funções oferecidas pelo sistema.

• Incluem, e.g., restrições sobre o processo de desenvolvimento e - Prof. Tavares padrões.
• Aplicam-se, frequentemente, ao sistema como um todo.
• Uma não conformidade pode comprometer todo o sistema.

Requisitos de produtos: especificam o comportamento do produto.

• Requisitos organizacionais: procedentes de políticas e - Prof. Tavares procedimentos nas organizações do cliente e do desenvolvedor.
• Requisitos externos: abrange os requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Incluem as caracteríticas de qualidade que o sistema deve possuir, devendo estas serem expressas quantitativamente, por meio de métricas que possam ser testadas. - Prof. Tavares
• As medições deverão ser feitas durante o teste de sistema, com a finalidade de se determinar se o sistema cumpre ou não com os requisitos.

Requisitos de Domínio

Requisitos que se originam do domínio de aplicação do sistema e que refletem características desse domínio.

• Geralmente incluem uma terminologia específica de domínio ou - Prof. Tavares fazem referência a conceitos do domínio.
• Podem ser funcionais ou não-funcionais.

Aplicação: Regras de negócio - restrições ou políticas de funcionamento específicas do domínio do problema.

Muitos problemas de Engenharia de Software têm sua origem na imprecisão da especificação de requisitos.

Qualidade é conformidade aos requisitos

O modelo de casos de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com o mesmo.

• Esse modelo representa os requisitos funcionais do - Prof. Tavares sistema.
• Também direciona diversas das atividades posteriores do ciclo de vida do sistema de software.
• Além disso, força os desenvolvedores a moldar o sistema de acordo com as necessidades do usuário.

Utilidade dos Casos de Uso

Equipe de clientes (validação) – aprovam o que o sistema deverá fazer – entendem o que o sistema deverá fazer

• Equipe de desenvolvedores - Prof. Tavares
  • Ponto de partida para refinar requisitos de software.
  • Podem seguir um desenvolvimento dirigido a casos de uso.
  • Designer (projetista): encontrar classes
  • Testadores: usam como base para casos de teste

Composição do MCU

O modelo de casos de uso de um sistema é composto de duas partes, uma textual, e outra gráfica.

• O diagrama da UML utilizado na modelagem de gráfica é o diagrama de casos de uso. - Prof. Tavares
  • Este diagrama permite dar uma visão global e de alto nível do sistema.
  • É também chamado de diagrama de contexto.
• Componentes: casos de uso, atores, relacionamentos entre os elementos anteriores.

Um caso de uso é a especificação de uma seqüência de interações entre um sistema e os agentes externos.

• Define parte da funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos deste sistema.
• Um modelo de casos de uso típico é formado de vários casos - Prof. Tavares de uso.
• Cada caso de uso é definido através da descrição textual das interações que ocorrem entre o(s) elemento(s) externo(s) e o sistema.
• Há várias “dimensões de estilo” para descrição de casos de uso: Grau de abstração; Formato; Grau de detalhamento.

Dimensões para Descrições Textuais

Um caso de uso é definido através da descrição textual das interações entre o(s) elemento(s) externo(s) e o sistema.

• Entretanto, a UML não define nada acerca de como essa descrição textual deve ser construída.
• Por conta disso, há várias dimensões - Prof. Tavares independentes sobres as quais a descrição textual de um caso de uso pode variar:
  • Grau de abstração (essencial ou real)
  • Formato (contínua, tabular, numerado)
  • Grau de detalhamento (sucinta ou expandida)

Formato

Exemplo de descrição contínua

Este caso de uso inicia quanto o Cliente chega ao caixa eletrônico e insere seu cartão. O Sistema requisita a senha do Cliente. Após o Cliente fornecer sua senha e

• Exemplo de descrição contínua - Prof. Tavares esta ser validada, o Sistema exibe as opções de operações possíveis. O Cliente opta por realizar um saque. Então o Sistema requisita o total a ser sacado. O Cliente fornece o valor da quantidade que deseja sacar. O Sistema fornece a quantia desejada e imprime o recibo para o Cliente. O Cliente retira a quantia e o recibo, e o caso de uso termina.

Cliente insere seu cartão no caixa eletrônico. 2) Sistema apresenta solicitação de senha. 3) Cliente digita senha. 4) Sistema valida a senha e exibe menu de operações

• Exemplo de descrição numerada - Prof. Tavares disponíveis. 5) Cliente indica que deseja realizar um saque. 6) Sistema requisita o valor da quantia a ser sacada. 7) Cliente fornece o valor da quantia que deseja sacar. 8) Sistema fornece a quantia desejada e imprime o recibo para o Cliente 9) Cliente retira a quantia e o recibo, e o caso de uso termina.

• Exemplo de descrição tabular - Prof. Tavares

Exemplo de descrição essencial (e numerada):

1. Cliente fornece sua identificação.
2. Sistema identifica o usuário.
3. Sistema fornece opções disponíveis para movimentação da conta. - Prof. Tavares
4. Cliente solicita o saque de uma determinada quantia.
5. Sistema requisita o valor da quantia a ser sacada.
6. Cliente fornece o valor da quantia que deseja sacar.
7. Sistema fornece a quantia desejada.
8. Cliente retira dinheiro e recibo e o caso de uso termina.

Atores

Elemento externo que interage com o sistema.

• “externo”: atores não fazem parte do sistema.
• “interage”: um ator troca informações com o sistema.
• Casos de uso representam uma seqüência de interações entre o sistema e o ator. - Prof. Tavares
  • no sentido de troca de informações entre eles.
• Normalmente um agente externo inicia a seqüência de interações com o sistema.

Categorias de atores:

• cargos (Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc);
• organizações (Empresa Fornecedora, Agência de Impostos, Administradora de Cartões, etc); - Prof. Tavares
• outros sistemas (Sistema de Cobrança, Sistema de Estoque de Produtos, etc).
• equipamentos (Leitora de Código de Barras, Sensor, etc.)
• Essa categorização indica para nós que o conceito de ator depende do escopo do sistema.

Um ator corresponde a um papel representado em relação ao sistema.

• O mesmo indivíduo pode ser o Cliente que compra mercadorias e o Vendedor que processa vendas.
• Uma pessoa pode representar o papel de Funcionário de - Prof. Tavares uma instituição bancária que realiza a manutenção de um caixa eletrônico, mas também pode ser o Cliente do banco que realiza o saque de uma quantia.
• O nome dado a um ator deve lembrar o seu papel, em vez de lembrar quem o representa.
  • e.g.: João Fernandes versus Fornecedor

Um ator representa um conjunto coerente de papéis que os usuários de casos desempenham quando interagem com o sistema

• Um caso de uso representa o que um ator quer que o sistema faça.
• Atores servem para definir o ambiente do sistema - Prof. Tavares
• Atores representam um papel exercido por uma pessoa ou por um sistema externo que interage com o sistema.
• Se comunicam enviando mensagens e/ou recebendo mensagens do sistema, conforme o caso de uso é executado
• Quando definimos o que os atores fazem e o que os casos de uso fazem, delimitamos, de forma clara, o escopo do sistema.