OOAD - Guia rápido

Uma breve história

O paradigma orientado a objetos tomou sua forma a partir do conceito inicial de uma nova abordagem de programação, enquanto o interesse em métodos de design e análise veio muito mais tarde.

  • A primeira linguagem orientada a objetos foi Simula (Simulação de sistemas reais), que foi desenvolvida em 1960 por pesquisadores do Centro de Computação Norueguês.

  • Em 1970, Alan Kay e seu grupo de pesquisa no Xerox PARK criaram um computador pessoal chamado Dynabook e a primeira linguagem de programação orientada a objetos (OOPL) pura - Smalltalk, para programar o Dynabook.

  • Na década de 1980, Grady Booch publicou um artigo intitulado Object Oriented Design que apresentou principalmente um design para a linguagem de programação, Ada. Nas edições seguintes, ele estendeu suas idéias para um método completo de design orientado a objetos.

  • Na década de 1990, Coad incorporou ideias comportamentais aos métodos orientados a objetos.

As outras inovações significativas foram Object Modeling Techniques (OMT), de James Rumbaugh, e Object-Oriented Software Engineering (OOSE), de Ivar Jacobson.

Análise Orientada a Objetos

Análise Orientada a Objetos (OOA) é o procedimento de identificação de requisitos de engenharia de software e desenvolvimento de especificações de software em termos de modelo de objeto de um sistema de software, que compreende objetos em interação.

A principal diferença entre a análise orientada a objetos e outras formas de análise é que, na abordagem orientada a objetos, os requisitos são organizados em torno de objetos, que integram dados e funções. Eles são modelados a partir de objetos do mundo real com os quais o sistema interage. Nas metodologias de análise tradicionais, os dois aspectos - funções e dados - são considerados separadamente.

Grady Booch definiu OOA como, “A análise orientada a objetos é um método de análise que examina os requisitos da perspectiva das classes e objetos encontrados no vocabulário do domínio do problema” .

As principais tarefas na análise orientada a objetos (OOA) são -

  • Identificando objetos
  • Organizando os objetos criando um diagrama de modelo de objeto
  • Definindo o interior dos objetos ou atributos do objeto
  • Definindo o comportamento dos objetos, ou seja, ações do objeto
  • Descrever como os objetos interagem

Os modelos comuns usados ​​em OOA são casos de uso e modelos de objeto.

Design Orientado a Objetos

O Projeto Orientado a Objetos (OOD) envolve a implementação do modelo conceitual produzido durante a análise orientada a objetos. No OOD, os conceitos do modelo de análise, que são independentes de tecnologia, são mapeados em classes de implementação, as restrições são identificadas e as interfaces são projetadas, resultando em um modelo para o domínio da solução, ou seja, uma descrição detalhada de como o sistema deve ser construído em tecnologias de concreto.

Os detalhes de implementação geralmente incluem -

  • Reestruturar os dados da classe (se necessário),
  • Implementação de métodos, ou seja, estruturas de dados internos e algoritmos,
  • Implementação de controle, e
  • Implementação de associações.

Grady Booch definiu o design orientado a objetos como “um método de design que abrange o processo de decomposição orientada a objetos e uma notação para representar modelos lógicos e físicos, bem como modelos estáticos e dinâmicos do sistema em design” .

Programação Orientada a Objetos

A programação orientada a objetos (OOP) é ​​um paradigma de programação baseado em objetos (contendo dados e métodos) que visa incorporar as vantagens da modularidade e da reutilização. Objetos, que geralmente são instâncias de classes, são usados ​​para interagir uns com os outros para projetar aplicativos e programas de computador.

As características importantes da programação orientada a objetos são -

  • Abordagem de baixo para cima na concepção do programa
  • Programas organizados em torno de objetos, agrupados em classes
  • Concentre-se nos dados com métodos para operar nos dados do objeto
  • Interação entre objetos por meio de funções
  • Reutilização do design por meio da criação de novas classes, adicionando recursos às classes existentes

Alguns exemplos de linguagens de programação orientadas a objetos são C ++, Java, Smalltalk, Delphi, C #, Perl, Python, Ruby e PHP.

Grady Booch definiu a programação orientada a objetos como "um método de implementação no qual os programas são organizados como coleções cooperativas de objetos, cada um dos quais representa uma instância de alguma classe, e cujas classes são todos membros de uma hierarquia de classes unidas por meio de relacionamentos de herança ” .

O modelo de objeto visualiza os elementos em um aplicativo de software em termos de objetos. Neste capítulo, examinaremos os conceitos básicos e as terminologias dos sistemas orientados a objetos.

Objetos e Classes

Os conceitos de objetos e classes estão intrinsecamente ligados uns aos outros e formam a base do paradigma orientado a objetos.

Objeto

Um objeto é um elemento do mundo real em um ambiente orientado a objetos que pode ter uma existência física ou conceitual. Cada objeto tem -

  • Identidade que o distingue de outros objetos no sistema.

  • Estado que determina as propriedades características de um objeto, bem como os valores das propriedades que o objeto contém.

  • Comportamento que representa atividades externamente visíveis realizadas por um objeto em termos de mudanças em seu estado.

Os objetos podem ser modelados de acordo com as necessidades da aplicação. Um objeto pode ter uma existência física, como um cliente, um carro, etc .; ou uma existência conceitual intangível, como um projeto, um processo, etc.

Classe

Uma classe representa uma coleção de objetos com as mesmas propriedades características que exibem um comportamento comum. Ele fornece o projeto ou a descrição dos objetos que podem ser criados a partir dele. A criação de um objeto como membro de uma classe é chamada de instanciação. Assim, objeto é uma instância de uma classe.

Os constituintes de uma classe são -

  • Um conjunto de atributos para os objetos que devem ser instanciados da classe. Geralmente, diferentes objetos de uma classe têm alguma diferença nos valores dos atributos. Os atributos geralmente são chamados de dados de classe.

  • Um conjunto de operações que retratam o comportamento dos objetos da classe. As operações também são chamadas de funções ou métodos.

Example

Vamos considerar uma classe simples, Circle, que representa o círculo da figura geométrica em um espaço bidimensional. Os atributos desta classe podem ser identificados da seguinte forma -

  • x – coord, para denotar a coordenada x do centro
  • coord y, para denotar a coordenada y do centro
  • a, para denotar o raio do círculo

Algumas de suas operações podem ser definidas da seguinte forma -

  • findArea (), método para calcular a área
  • findCircumference (), método para calcular a circunferência
  • escala (), método para aumentar ou diminuir o raio

Durante a instanciação, os valores são atribuídos a pelo menos alguns dos atributos. Se criarmos um objeto my_circle, podemos atribuir valores como x-coord: 2, y-coord: 3 e a: 4 para representar seu estado. Agora, se a operação scale () for realizada em my_circle com um fator de escala de 2, o valor da variável a se tornará 8. Esta operação traz uma mudança no estado de my_circle, ou seja, o objeto exibiu certo comportamento.

Encapsulamento e ocultação de dados

Encapsulamento

Encapsulamento é o processo de vincular atributos e métodos dentro de uma classe. Por meio do encapsulamento, os detalhes internos de uma classe podem ser ocultados de fora. Ele permite que os elementos da classe sejam acessados ​​de fora apenas por meio da interface fornecida pela classe.

Ocultação de dados

Normalmente, uma classe é projetada de forma que seus dados (atributos) possam ser acessados ​​apenas por seus métodos de classe e isolados do acesso externo direto. Este processo de isolar os dados de um objeto é chamado de ocultação de dados ou ocultação de informações.

Example

Na classe Circle, o ocultamento de dados pode ser incorporado tornando os atributos invisíveis de fora da classe e adicionando mais dois métodos à classe para acessar os dados da classe, a saber -

  • setValues ​​(), método para atribuir valores a x-coord, y-coord, e a
  • getValues ​​(), método para recuperar os valores de x-coord, y-coord, e a

Aqui, os dados privados do objeto my_circle não podem ser acessados ​​diretamente por nenhum método que não esteja encapsulado na classe Circle. Em vez disso, ele deve ser acessado por meio dos métodos setValues ​​() e getValues ​​().

Passagem de mensagens

Qualquer aplicação requer uma série de objetos interagindo de maneira harmoniosa. Os objetos em um sistema podem se comunicar uns com os outros usando a passagem de mensagens. Suponha que um sistema tenha dois objetos: obj1 e obj2. O objeto obj1 envia uma mensagem ao objeto obj2, se obj1 deseja que obj2 execute um de seus métodos.

Os recursos de passagem de mensagens são -

  • A passagem de mensagens entre dois objetos é geralmente unidirecional.
  • A passagem de mensagens permite todas as interações entre objetos.
  • A passagem de mensagens envolve essencialmente a invocação de métodos de classe.
  • Objetos em processos diferentes podem estar envolvidos na passagem de mensagens.

Herança

Herança é o mecanismo que permite que novas classes sejam criadas a partir de classes existentes, estendendo e refinando seus recursos. As classes existentes são chamadas de classes base / classes pai / superclasses, e as novas classes são chamadas de classes derivadas / classes filho / subclasses. A subclasse pode herdar ou derivar os atributos e métodos da (s) superclasse (s), desde que a superclasse assim o permita. Além disso, a subclasse pode adicionar seus próprios atributos e métodos e pode modificar qualquer um dos métodos da superclasse. Herança define um relacionamento “é um”.

Example

De uma classe Mamífero, várias classes podem ser derivadas, como Humano, Gato, Cão, Vaca, etc. Humanos, gatos, cães e vacas têm características distintas de mamíferos. Além disso, cada um tem suas características particulares. Pode-se dizer que uma vaca “é - um” mamífero.

Tipos de herança

  • Single Inheritance - Uma subclasse deriva de uma única superclasse.

  • Multiple Inheritance - Uma subclasse deriva de mais de uma superclasse.

  • Multilevel Inheritance - Uma subclasse deriva de uma superclasse que, por sua vez, é derivada de outra classe e assim por diante.

  • Hierarchical Inheritance - Uma classe tem várias subclasses, cada uma das quais pode ter subclasses subsequentes, continuando por vários níveis, de modo a formar uma estrutura em árvore.

  • Hybrid Inheritance - Uma combinação de herança múltipla e multinível de modo a formar uma estrutura de rede.

A figura a seguir descreve os exemplos de diferentes tipos de herança.

Polimorfismo

Polimorfismo é originalmente uma palavra grega que significa a capacidade de assumir várias formas. No paradigma orientado a objetos, o polimorfismo implica o uso de operações de maneiras diferentes, dependendo da instância na qual estão operando. O polimorfismo permite que objetos com diferentes estruturas internas tenham uma interface externa comum. O polimorfismo é particularmente eficaz ao implementar a herança.

Example

Vamos considerar duas classes, Circle e Square, cada uma com um método findArea (). Embora o nome e a finalidade dos métodos nas classes sejam os mesmos, a implementação interna, ou seja, o procedimento de cálculo da área é diferente para cada classe. Quando um objeto da classe Circle invoca seu método findArea (), a operação encontra a área do círculo sem nenhum conflito com o método findArea () da classe Square.

Generalização e Especialização

Generalização e especialização representam uma hierarquia de relacionamentos entre classes, em que as subclasses herdam de superclasses.

Generalização

No processo de generalização, as características comuns das classes são combinadas para formar uma classe em um nível superior de hierarquia, ou seja, as subclasses são combinadas para formar uma superclasse generalizada. Representa um relacionamento “é - um - tipo - de”. Por exemplo, “carro é um tipo de veículo terrestre” ou “navio é um tipo de veículo aquático”.

Especialização

A especialização é o processo reverso de generalização. Aqui, os recursos distintivos de grupos de objetos são usados ​​para formar classes especializadas a partir de classes existentes. Pode-se dizer que as subclasses são as versões especializadas da superclasse.

A figura a seguir mostra um exemplo de generalização e especialização.

Links e associação

Ligação

Um link representa uma conexão por meio da qual um objeto colabora com outros objetos. Rumbaugh a definiu como “uma conexão física ou conceitual entre objetos”. Por meio de um link, um objeto pode invocar os métodos ou navegar por outro objeto. Um link descreve o relacionamento entre dois ou mais objetos.

Associação

Associação é um grupo de links com estrutura e comportamento comuns. A associação representa o relacionamento entre objetos de uma ou mais classes. Um link pode ser definido como uma instância de uma associação.

Grau de uma associação

O grau de uma associação denota o número de classes envolvidas em uma conexão. O grau pode ser unário, binário ou ternário.

  • UMA unary relationship conecta objetos da mesma classe.

  • UMA binary relationship conecta objetos de duas classes.

  • UMA ternary relationship conecta objetos de três ou mais classes.

Razões de cardinalidade de associações

A cardinalidade de uma associação binária denota o número de instâncias que participam de uma associação. Existem três tipos de razões de cardinalidade, a saber -

  • One–to–One - Um único objeto da classe A está associado a um único objeto da classe B.

  • One–to–Many - Um único objeto da classe A está associado a muitos objetos da classe B.

  • Many–to–Many - Um objeto da classe A pode estar associado a muitos objetos da classe B e, inversamente, um objeto da classe B pode estar associado a muitos objetos da classe A.

Agregação ou Composição

Agregação ou composição é um relacionamento entre classes pelo qual uma classe pode ser composta de qualquer combinação de objetos de outras classes. Ele permite que os objetos sejam colocados diretamente no corpo de outras classes. A agregação é referida como um relacionamento “parte de” ou “tem um”, com a capacidade de navegar do todo para suas partes. Um objeto agregado é um objeto composto por um ou mais outros objetos.

Example

Na relação, “um carro tem um motor”, o carro é o objeto inteiro ou o agregado, e o motor é uma “parte” do carro. A agregação pode denotar -

  • Physical containment - Por exemplo, um computador é composto de monitor, CPU, mouse, teclado e assim por diante.

  • Conceptual containment - Exemplo, o acionista possui uma ação.

Benefícios do modelo de objeto

Agora que examinamos os principais conceitos relativos à orientação a objetos, vale a pena observar as vantagens que este modelo tem a oferecer.

Os benefícios de usar o modelo de objeto são -

  • Ajuda no desenvolvimento mais rápido de software.

  • É fácil de manter. Suponha que um módulo desenvolva um erro, então um programador pode consertar esse módulo específico, enquanto as outras partes do software ainda estão funcionando.

  • Ele oferece suporte a atualizações relativamente fáceis.

  • Ele permite a reutilização de objetos, designs e funções.

  • Reduz os riscos de desenvolvimento, especialmente na integração de sistemas complexos.

Sabemos que a técnica Object-Oriented Modeling (OOM) visualiza coisas em um aplicativo usando modelos organizados em torno de objetos. Qualquer abordagem de desenvolvimento de software passa pelos seguintes estágios -

  • Analysis,
  • Design e
  • Implementation.

Na engenharia de software orientada a objetos, o desenvolvedor de software identifica e organiza o aplicativo em termos de conceitos orientados a objetos, antes de sua representação final em qualquer linguagem de programação ou ferramentas de software específicas.

Fases no desenvolvimento de software orientado a objetos

As principais fases do desenvolvimento de software usando metodologia orientada a objetos são análise orientada a objetos, design orientado a objetos e implementação orientada a objetos.

Análise Orientada a Objetos

Nesse estágio, o problema é formulado, os requisitos do usuário são identificados e, em seguida, um modelo é construído com base em objetos do mundo real. A análise produz modelos sobre como o sistema desejado deve funcionar e como deve ser desenvolvido. Os modelos não incluem quaisquer detalhes de implementação para que possam ser entendidos e examinados por qualquer especialista não técnico em aplicativos.

Design Orientado a Objetos

O design orientado a objetos inclui dois estágios principais, a saber, design de sistema e design de objeto.

System Design

Nesta etapa, é desenhada a arquitetura completa do sistema desejado. O sistema é concebido como um conjunto de subsistemas em interação que, por sua vez, é composto por uma hierarquia de objetos em interação, agrupados em classes. O projeto do sistema é feito de acordo com o modelo de análise do sistema e a arquitetura do sistema proposta. Aqui, a ênfase está nos objetos que compõem o sistema, e não nos processos do sistema.

Object Design

Nesta fase, um modelo de design é desenvolvido com base nos modelos desenvolvidos na fase de análise do sistema e na arquitetura projetada na fase de design do sistema. Todas as classes necessárias são identificadas. O designer decide se -

  • novas classes devem ser criadas do zero,
  • qualquer classe existente pode ser usada em sua forma original, ou
  • novas classes devem ser herdadas das classes existentes.

As associações entre as classes identificadas são estabelecidas e as hierarquias de classes são identificadas. Além disso, o desenvolvedor projeta os detalhes internos das classes e suas associações, ou seja, a estrutura de dados para cada atributo e os algoritmos para as operações.

Implementação e teste orientados a objetos

Nesta fase, o modelo de design desenvolvido no design do objeto é traduzido em código em uma linguagem de programação ou ferramenta de software apropriada. Os bancos de dados são criados e os requisitos de hardware específicos são verificados. Quando o código está em forma, ele é testado usando técnicas especializadas para identificar e remover os erros do código.

Princípios de Sistemas Orientados a Objetos

A estrutura conceitual dos sistemas orientados a objetos é baseada no modelo de objetos. Existem duas categorias de elementos em um sistema orientado a objetos -

Major Elements- Por major, entende-se que se um modelo não possuir nenhum desses elementos, ele deixa de ser orientado a objetos. Os quatro elementos principais são -

  • Abstraction
  • Encapsulation
  • Modularity
  • Hierarchy

Minor Elements- Por menor, significa que esses elementos são úteis, mas não parte indispensável do modelo de objeto. Os três elementos menores são -

  • Typing
  • Concurrency
  • Persistence

Abstração

Abstração significa focar nas características essenciais de um elemento ou objeto em OOP, ignorando suas propriedades estranhas ou acidentais. Os recursos essenciais são relativos ao contexto no qual o objeto está sendo usado.

Grady Booch definiu abstração da seguinte forma -

“Uma abstração denota as características essenciais de um objeto que o distinguem de todos os outros tipos de objetos e, portanto, fornecem limites conceituais nitidamente definidos, em relação à perspectiva do observador.”

Example - Quando uma classe Aluno é projetada, os atributos matricula_number, nome, curso e endereço são incluídos, enquanto características como pulse_rate e size_of_shoe são eliminadas, uma vez que são irrelevantes na perspectiva da instituição de ensino.

Encapsulamento

Encapsulamento é o processo de vincular atributos e métodos dentro de uma classe. Por meio do encapsulamento, os detalhes internos de uma classe podem ser ocultados de fora. A classe possui métodos que fornecem interfaces de usuário pelas quais os serviços fornecidos pela classe podem ser usados.

Modularidade

Modularidade é o processo de decompor um problema (programa) em um conjunto de módulos de modo a reduzir a complexidade geral do problema. Booch definiu modularidade como -

“Modularidade é a propriedade de um sistema que foi decomposto em um conjunto de módulos coesos e fracamente acoplados.”

A modularidade está intrinsecamente ligada ao encapsulamento. A modularidade pode ser visualizada como uma forma de mapear abstrações encapsuladas em módulos físicos reais com alta coesão dentro dos módulos e sua interação ou acoplamento entre módulos é baixa.

Hierarquia

Nas palavras de Grady Booch, “Hierarquia é a classificação ou ordenação da abstração”. Por meio da hierarquia, um sistema pode ser formado por subsistemas inter-relacionados, que podem ter seus próprios subsistemas e assim por diante, até que os menores componentes de nível sejam alcançados. Ele usa o princípio de “dividir para conquistar”. A hierarquia permite a reutilização do código.

Os dois tipos de hierarquias em OOA são -

  • “IS–A” hierarchy- Define a relação hierárquica na herança, por meio da qual, de uma superclasse, várias subclasses podem ser derivadas, as quais podem ter subclasses novamente e assim por diante. Por exemplo, se derivarmos uma classe Rosa de uma classe Flor, podemos dizer que uma rosa “é – uma” flor.

  • “PART–OF” hierarchy- Define a relação hierárquica de agregação pela qual uma classe pode ser composta por outras classes. Por exemplo, uma flor é composta de sépalas, pétalas, estames e carpelo. Pode-se dizer que uma pétala é uma “parte” da flor.

Digitando

De acordo com as teorias de tipo abstrato de dados, um tipo é uma caracterização de um conjunto de elementos. Em OOP, uma classe é visualizada como um tipo com propriedades distintas de quaisquer outros tipos. A digitação é a aplicação da noção de que um objeto é uma instância de uma única classe ou tipo. Ele também impõe que objetos de diferentes tipos geralmente não sejam trocados; e só pode ser intercambiado de uma maneira muito restrita se for absolutamente necessário.

Os dois tipos de digitação são -

  • Strong Typing - Aqui, a operação em um objeto é verificada no momento da compilação, como na linguagem de programação Eiffel.

  • Weak Typing- Aqui, as mensagens podem ser enviadas para qualquer turma. A operação é verificada apenas no momento da execução, como na linguagem de programação Smalltalk.

Simultaneidade

A simultaneidade em sistemas operacionais permite realizar várias tarefas ou processos simultaneamente. Quando existe um único processo em um sistema, diz-se que existe um único thread de controle. No entanto, a maioria dos sistemas tem vários threads, alguns ativos, alguns esperando pela CPU, alguns suspensos e alguns encerrados. Sistemas com múltiplas CPUs permitem inerentemente threads de controle simultâneos; mas os sistemas rodando em uma única CPU usam algoritmos apropriados para dar tempo de CPU equitativo aos threads de modo a permitir a simultaneidade.

Em um ambiente orientado a objetos, existem objetos ativos e inativos. Os objetos ativos têm threads de controle independentes que podem ser executados simultaneamente com threads de outros objetos. Os objetos ativos são sincronizados entre si e também com objetos puramente sequenciais.

Persistência

Um objeto ocupa um espaço de memória e existe por um determinado período de tempo. Na programação tradicional, o tempo de vida de um objeto era tipicamente o tempo de execução do programa que o criou. Em arquivos ou bancos de dados, a vida útil do objeto é maior do que a duração do processo de criação do objeto. Essa propriedade pela qual um objeto continua a existir mesmo depois que seu criador deixa de existir é conhecida como persistência.

Na fase de análise do sistema ou análise orientada a objetos do desenvolvimento de software, os requisitos do sistema são determinados, as classes são identificadas e os relacionamentos entre as classes são identificados.

As três técnicas de análise que são usadas em conjunto umas com as outras para análise orientada a objetos são modelagem de objetos, modelagem dinâmica e modelagem funcional.

Modelagem de Objetos

A modelagem de objetos desenvolve a estrutura estática do sistema de software em termos de objetos. Ele identifica os objetos, as classes nas quais os objetos podem ser agrupados e os relacionamentos entre os objetos. Também identifica os principais atributos e operações que caracterizam cada classe.

O processo de modelagem de objetos pode ser visualizado nas seguintes etapas -

  • Identificar objetos e agrupar em classes
  • Identifique as relações entre as classes
  • Criar diagrama de modelo de objeto de usuário
  • Definir atributos de objeto de usuário
  • Defina as operações que devem ser realizadas nas aulas
  • Rever glossário

Modelagem Dinâmica

Depois que o comportamento estático do sistema é analisado, seu comportamento em relação ao tempo e às mudanças externas precisa ser examinado. Este é o objetivo da modelagem dinâmica.

A Modelagem Dinâmica pode ser definida como “uma maneira de descrever como um objeto individual responde a eventos, sejam eventos internos acionados por outros objetos, ou eventos externos acionados pelo mundo exterior”.

O processo de modelagem dinâmica pode ser visualizado nas seguintes etapas -

  • Identifique os estados de cada objeto
  • Identificar eventos e analisar a aplicabilidade das ações
  • Construir diagrama de modelo dinâmico, composto por diagramas de transição de estado
  • Expresse cada estado em termos de atributos de objeto
  • Valide os diagramas de transição de estado desenhados

Modelagem Funcional

A modelagem funcional é o componente final da análise orientada a objetos. O modelo funcional mostra os processos executados em um objeto e como os dados mudam à medida que se movem entre os métodos. Ele especifica o significado das operações de modelagem de objetos e as ações de modelagem dinâmica. O modelo funcional corresponde ao diagrama de fluxo de dados da análise estruturada tradicional.

O processo de modelagem funcional pode ser visualizado nas seguintes etapas -

  • Identifique todas as entradas e saídas
  • Construir diagramas de fluxo de dados mostrando dependências funcionais
  • Indique o propósito de cada função
  • Identifique as restrições
  • Especifique os critérios de otimização

Análise Estruturada vs. Análise Orientada a Objetos

A abordagem Structured Analysis / Structured Design (SASD) é a abordagem tradicional de desenvolvimento de software com base no modelo em cascata. As fases de desenvolvimento de um sistema usando SASD são -

  • Estudo de viabilidade
  • Análise e Especificação de Requisitos
  • Projeto de sistema
  • Implementation
  • Revisão pós-implementação

Agora, veremos as vantagens e desvantagens relativas da abordagem de análise estruturada e da abordagem de análise orientada a objetos.

Vantagens / desvantagens da análise orientada a objetos

Vantagens Desvantagens
Concentra-se em dados em vez de procedimentos como na Análise Estruturada. A funcionalidade é restrita aos objetos. Isso pode representar um problema para sistemas que são intrinsecamente procedimentais ou computacionais por natureza.
Os princípios de encapsulamento e ocultação de dados ajudam o desenvolvedor a desenvolver sistemas que não podem ser violados por outras partes do sistema. Ele não pode identificar quais objetos gerariam um design de sistema ideal.
Os princípios de encapsulamento e ocultação de dados ajudam o desenvolvedor a desenvolver sistemas que não podem ser violados por outras partes do sistema. Os modelos orientados a objetos não mostram facilmente as comunicações entre os objetos no sistema.
Ele permite o gerenciamento eficaz da complexidade do software em virtude da modularidade. Todas as interfaces entre os objetos não podem ser representadas em um único diagrama.
Ele pode ser atualizado de sistemas pequenos para grandes com mais facilidade do que em sistemas que seguem uma análise estruturada.

Vantagens / desvantagens da análise estruturada

Vantagens Desvantagens
Como segue uma abordagem de cima para baixo em contraste com a abordagem de baixo para cima da análise orientada a objetos, pode ser mais facilmente compreendida do que OOA. Em modelos de análise estruturados tradicionais, uma fase deve ser concluída antes da próxima fase. Isso representa um problema de design, especialmente se ocorrerem erros ou se os requisitos forem alterados.
É baseado na funcionalidade. O propósito geral é identificado e, em seguida, a decomposição funcional é feita para desenvolver o software. A ênfase não só dá uma melhor compreensão do sistema, mas também gera sistemas mais completos. O custo inicial de construção do sistema é alto, uma vez que todo o sistema precisa ser projetado de uma vez, deixando poucas opções para adicionar funcionalidade posteriormente.
As especificações são escritas em inglês simples e, portanto, podem ser analisadas mais facilmente por pessoal não técnico. Ele não oferece suporte à reutilização de código. Portanto, o tempo e o custo de desenvolvimento são inerentemente altos.

O modelo dinâmico representa os aspectos dependentes do tempo de um sistema. Está preocupado com as mudanças temporais nos estados dos objetos em um sistema. Os principais conceitos são -

  • Estado, que é a situação em uma condição particular durante a vida útil de um objeto.

  • Transição, uma mudança de estado

  • Evento, uma ocorrência que desencadeia transições

  • Ação, uma computação ininterrupta e atômica que ocorre devido a algum evento, e

  • Simultaneidade de transições.

Uma máquina de estado modela o comportamento de um objeto à medida que ele passa por uma série de estados em sua vida devido a alguns eventos, bem como às ações que ocorrem devido aos eventos. Uma máquina de estado é representada graficamente por meio de um diagrama de transição de estado.

Estados e transições de estado

Estado

O estado é uma abstração dada pelos valores dos atributos que o objeto possui em um determinado período de tempo. É uma situação que ocorre por um período de tempo finito na vida de um objeto, no qual ele atende a certas condições, executa certas atividades ou espera que certos eventos ocorram. Em diagramas de transição de estado, um estado é representado por retângulos arredondados.

Partes de um estado

  • Name- Uma string diferencia um estado de outro. Um estado não pode ter nenhum nome.

  • Entry/Exit Actions - Denota as atividades realizadas na entrada e na saída do estado.

  • Internal Transitions - As mudanças dentro de um estado que não causam uma mudança no estado.

  • Sub–states - Estados dentro de Estados.

Estados iniciais e finais

O estado inicial padrão de um objeto é chamado de estado inicial. O estado final indica a conclusão da execução da máquina de estado. Os estados inicial e final são pseudo-estados e não podem ter as partes de um estado regular, exceto o nome. Em diagramas de transição de estado, o estado inicial é representado por um círculo preto preenchido. O estado final é representado por um círculo preto preenchido dentro de outro círculo preto não preenchido.

Transição

Uma transição denota uma mudança no estado de um objeto. Se um objeto estiver em um determinado estado quando um evento ocorrer, o objeto pode executar certas atividades sujeitas a condições especificadas e alterar o estado. Nesse caso, diz-se que ocorreu uma transição de estado. A transição fornece a relação entre o primeiro estado e o novo estado. Uma transição é representada graficamente por um arco sólido direcionado do estado de origem ao estado de destino.

As cinco partes de uma transição são -

  • Source State - O estado afetado pela transição.

  • Event Trigger - A ocorrência devido à qual um objeto no estado de origem sofre uma transição se a condição de guarda for satisfeita.

  • Guard Condition - Uma expressão booleana que, se True, causa uma transição ao receber o gatilho do evento.

  • Action - Um cálculo atômico ininterrupto que ocorre no objeto de origem devido a algum evento.

  • Target State - O estado de destino após a conclusão da transição.

Example

Suponha que uma pessoa esteja pegando um táxi do ponto X para o local Y. Os estados da pessoa podem ser: Esperando (esperando pelo táxi), Pedalando (ela pegou um táxi e está viajando nele) e Alcançado (ela alcançou o destino). A figura a seguir descreve a transição de estado.

Eventos

Eventos são algumas ocorrências que podem acionar a transição de estado de um objeto ou grupo de objetos. Os eventos têm uma localização no tempo e no espaço, mas não têm um período de tempo associado a eles. Os eventos geralmente são associados a algumas ações.

Exemplos de eventos são clique do mouse, pressionamento de tecla, uma interrupção, estouro de pilha, etc.

Os eventos que disparam as transições são escritos ao lado do arco de transição nos diagramas de estado.

Example

Considerando o exemplo mostrado na figura acima, a transição do estado Esperando para o estado Pedalando ocorre quando a pessoa pega um táxi. Da mesma forma, o estado final é alcançado, quando ele chega ao destino. Essas duas ocorrências podem ser chamadas de eventos Get_Taxi e Reach_Destination. A figura a seguir mostra os eventos em uma máquina de estado.

Eventos Externos e Internos

Eventos externos são aqueles eventos que passam de um usuário do sistema para os objetos dentro do sistema. Por exemplo, clique do mouse ou pressionamento de tecla pelo usuário são eventos externos.

Eventos internos são aqueles que passam de um objeto para outro dentro de um sistema. Por exemplo, estouro de pilha, erro de divisão, etc.

Eventos Adiados

Os eventos adiados são aqueles que não são tratados imediatamente pelo objeto no estado atual, mas são alinhados em uma fila para que possam ser tratados pelo objeto em algum outro estado posteriormente.

Aulas de Eventos

A classe de eventos indica um grupo de eventos com estrutura e comportamento comuns. Assim como acontece com as classes de objetos, as classes de eventos também podem ser organizadas em uma estrutura hierárquica. As classes de eventos podem ter atributos associados a elas, sendo o tempo um atributo implícito. Por exemplo, podemos considerar os eventos de partida de um voo de uma companhia aérea, que podemos agrupar na seguinte classe -

Flight_Departs (Flight_No, From_City, To_City, Route)

Ações

Atividade

Atividade é uma operação sobre os estados de um objeto que requer algum período de tempo. Eles são as execuções em andamento dentro de um sistema que podem ser interrompidas. As atividades são mostradas em diagramas de atividades que retratam o fluxo de uma atividade para outra.

Açao

Uma ação é uma operação atômica executada como resultado de certos eventos. Por atômico, significa que as ações são ininterruptas, ou seja, se uma ação começar a ser executada, ela será concluída sem ser interrompida por nenhum evento. Uma ação pode operar em um objeto no qual um evento foi disparado ou em outros objetos que são visíveis para este objeto. Um conjunto de ações compreende uma atividade.

Ações de entrada e saída

A ação de entrada é a ação executada ao entrar em um estado, independentemente da transição que levou a ele.

Da mesma forma, a ação executada ao sair de um estado, independentemente da transição que o conduziu para fora dele, é chamada de ação de saída.

Cenário

O cenário é uma descrição de uma sequência específica de ações. Ele descreve o comportamento de objetos submetidos a uma série de ações específicas. Os cenários primários representam as sequências essenciais e os cenários secundários representam as sequências alternativas.

Diagramas para modelagem dinâmica

Existem dois diagramas primários que são usados ​​para modelagem dinâmica -

Diagramas de interação

Os diagramas de interação descrevem o comportamento dinâmico entre diferentes objetos. É composto por um conjunto de objetos, seus relacionamentos e a mensagem que os objetos enviam e recebem. Assim, uma interação modela o comportamento de um grupo de objetos inter-relacionados. Os dois tipos de diagramas de interação são -

  • Sequence Diagram - Representa a ordem temporal das mensagens de forma tabular.

  • Collaboration Diagram - Representa a organização estrutural dos objetos que enviam e recebem mensagens por meio de vértices e arcos.

Diagrama de Transição de Estado

Os diagramas de transição de estado ou máquinas de estado descrevem o comportamento dinâmico de um único objeto. Ele ilustra as sequências de estados pelas quais um objeto passa em seu tempo de vida, as transições dos estados, os eventos e condições que causam a transição e as respostas devido aos eventos.

Simultaneidade de eventos

Em um sistema, podem existir dois tipos de simultaneidade. Eles são -

Simultaneidade do sistema

Aqui, a simultaneidade é modelada no nível do sistema. O sistema geral é modelado como a agregação de máquinas de estado, onde cada máquina de estado é executada simultaneamente com outras.

Simultaneidade dentro de um objeto

Aqui, um objeto pode emitir eventos simultâneos. Um objeto pode ter estados compostos de subestados e eventos simultâneos podem ocorrer em cada um dos subestados.

Os conceitos relacionados à simultaneidade dentro de um objeto são os seguintes -

Estados simples e compostos

Um estado simples não tem subestrutura. Um estado que possui estados mais simples aninhados dentro dele é chamado de estado composto. Um subestado é um estado aninhado dentro de outro estado. Geralmente é usado para reduzir a complexidade de uma máquina de estado. Os subestados podem ser aninhados em qualquer número de níveis.

Os estados compostos podem ter subestados sequenciais ou subestados simultâneos.

Subestados Sequenciais

Em subestados sequenciais, o controle de execução passa de um subestado para outro, um após o outro, de maneira sequencial. Há no máximo um estado inicial e um estado final nessas máquinas de estado.

A figura a seguir ilustra o conceito de subestados sequenciais.

Subestados simultâneos

Em subestados simultâneos, os subestados são executados em paralelo, ou em outras palavras, cada estado possui máquinas de estado em execução simultânea dentro dele. Cada uma das máquinas de estado tem seus próprios estados inicial e final. Se um subestado simultâneo atinge seu estado final antes do outro, o controle espera em seu estado final. Quando todas as máquinas de estado aninhadas alcançam seus estados finais, os subestados se unem de volta a um único fluxo.

A figura a seguir mostra o conceito de subestados simultâneos.

A Modelagem Funcional fornece a perspectiva do processo do modelo de análise orientada a objetos e uma visão geral do que o sistema deve fazer. Ele define a função dos processos internos do sistema com o auxílio de Diagramas de Fluxo de Dados (DFDs). Ele descreve a derivação funcional dos valores dos dados sem indicar como eles são derivados quando são calculados ou por que precisam ser calculados.

Diagramas de fluxo de dados

A modelagem funcional é representada por uma hierarquia de DFDs. O DFD é uma representação gráfica de um sistema que mostra as entradas para o sistema, o processamento nas entradas, as saídas do sistema, bem como os armazenamentos de dados internos. Os DFDs ilustram a série de transformações ou cálculos realizados nos objetos ou no sistema e os controles externos e objetos que afetam a transformação.

Rumbaugh et al. definiram DFD como, “Um diagrama de fluxo de dados é um gráfico que mostra o fluxo de valores de dados de suas fontes em objetos por meio de processos que os transformam em seus destinos em outros objetos.”

As quatro partes principais de um DFD são -

  • Processes,
  • Fluxos de dados,
  • Atores e
  • Armazenamentos de dados.

As outras partes de um DFD são -

  • Restrições e
  • Fluxos de controle.

Características de um DFD

Processos

Processos são atividades computacionais que transformam os valores dos dados. Todo um sistema pode ser visualizado como um processo de alto nível. Um processo pode ser dividido em componentes menores. O processo de nível mais baixo pode ser uma função simples.

Representation in DFD - Um processo é representado como uma elipse com seu nome escrito dentro dele e contém um número fixo de valores de dados de entrada e saída.

Example - A figura a seguir mostra um processo Compute_HCF_LCM que aceita dois inteiros como entradas e saídas seu HCF (fator comum mais alto) e LCM (mínimo múltiplo comum).

Fluxos de Dados

O fluxo de dados representa o fluxo de dados entre dois processos. Pode ser entre um ator e um processo, ou entre um armazenamento de dados e um processo. Um fluxo de dados denota o valor de um item de dados em algum ponto do cálculo. Este valor não é alterado pelo fluxo de dados.

Representation in DFD - Um fluxo de dados é representado por um arco direcionado ou uma seta, rotulado com o nome do item de dados que ele carrega.

Na figura acima, Integer_a e Integer_b representam os fluxos de dados de entrada para o processo, enquanto LCM e HCF são os fluxos de dados de saída.

Um fluxo de dados pode ser bifurcado nos seguintes casos -

  • O valor de saída é enviado para vários lugares, conforme mostrado na figura a seguir. Aqui, as setas de saída não estão marcadas, pois denotam o mesmo valor.

  • O fluxo de dados contém um valor agregado e cada um dos componentes é enviado para locais diferentes, conforme mostrado na figura a seguir. Aqui, cada um dos componentes bifurcados é rotulado.

Atores

Atores são os objetos ativos que interagem com o sistema, produzindo dados e inserindo-os no sistema, ou consumindo dados produzidos pelo sistema. Em outras palavras, os atores servem como fontes e sumidouros de dados.

Representation in DFD- Um ator é representado por um retângulo. Os atores são conectados às entradas e saídas e ficam no limite do DFD.

Example - A figura a seguir mostra os atores, a saber, Customer e Sales_Clerk em um sistema de contra venda.

Armazenamento de dados

Os armazenamentos de dados são os objetos passivos que atuam como repositórios de dados. Ao contrário dos atores, eles não podem realizar nenhuma operação. Eles são usados ​​para armazenar dados e recuperar os dados armazenados. Eles representam uma estrutura de dados, um arquivo de disco ou uma tabela em um banco de dados.

Representation in DFD- Um armazenamento de dados é representado por duas linhas paralelas contendo o nome do armazenamento de dados. Cada armazenamento de dados está conectado a pelo menos um processo. As setas de entrada contêm informações para modificar o conteúdo do armazenamento de dados, enquanto as setas de saída contêm informações recuperadas do armazenamento de dados. Quando uma parte das informações deve ser recuperada, a seta de saída é rotulada. Uma seta sem etiqueta indica a recuperação total dos dados. Uma seta bidirecional implica em recuperação e atualização.

Example- A figura a seguir mostra um armazenamento de dados, Sales_Record, que armazena os detalhes de todas as vendas. A entrada para o armazenamento de dados compreende detalhes de vendas, como item, valor de faturamento, data, etc. Para encontrar a média de vendas, o processo recupera os registros de vendas e calcula a média.

Restrições

As restrições especificam as condições ou restrições que precisam ser satisfeitas ao longo do tempo. Eles permitem adicionar novas regras ou modificar as existentes. As restrições podem aparecer em todos os três modelos de análise orientada a objetos.

  • Na modelagem de objetos, as restrições definem o relacionamento entre os objetos. Eles também podem definir a relação entre os diferentes valores que um objeto pode assumir em momentos diferentes.

  • Na Modelagem Dinâmica, as restrições definem o relacionamento entre os estados e eventos de diferentes objetos.

  • Na Modelagem Funcional, as restrições definem as restrições nas transformações e cálculos.

Representation - Uma restrição é representada como uma string entre colchetes.

Example- A figura a seguir mostra uma parcela do DFD para calcular o salário dos funcionários de uma empresa que decidiu dar incentivos a todos os funcionários do departamento de vendas e incrementar o salário de todos os funcionários do departamento de RH. Pode ser visto que a restrição {Departamento: Vendas} faz com que o incentivo seja calculado apenas se o departamento for de vendas e a restrição {Departamento: RH} faz com que o incremento seja calculado apenas se o departamento for RH.

Fluxos de controle

Um processo pode ser associado a um determinado valor booleano e é avaliado apenas se o valor for verdadeiro, embora não seja uma entrada direta para o processo. Esses valores booleanos são chamados de fluxos de controle.

Representation in DFD - Os fluxos de controle são representados por um arco pontilhado do processo que produz o valor booleano até o processo por ele controlado.

Example- A figura a seguir representa um DFD para divisão aritmética. O Divisor foi testado para valores diferentes de zero. Se não for zero, o fluxo de controle OK tem um valor True e, posteriormente, o processo de Divisão calcula o Quociente e o Restante.

Desenvolvendo o modelo DFD de um sistema

Para desenvolver o modelo DFD de um sistema, uma hierarquia de DFDs é construída. O DFD de nível superior compreende um único processo e os atores que interagem com ele.

Em cada nível inferior sucessivo, detalhes adicionais são gradualmente incluídos. Um processo é decomposto em subprocessos, os fluxos de dados entre os subprocessos são identificados, os fluxos de controle são determinados e os armazenamentos de dados são definidos. Ao decompor um processo, o fluxo de dados para dentro ou para fora do processo deve corresponder ao fluxo de dados no próximo nível de DFD.

Example- Consideremos um sistema de software, Software Atacadista, que automatiza as transações de uma loja de atacado. A loja vende a granel e tem uma clientela composta por comerciantes e lojistas. Cada cliente é solicitado a registrar-se com seus dados pessoais e recebe um código de cliente exclusivo, C_Code. Feita a venda, a loja registra seus dados e envia a mercadoria para o envio. A cada ano, a loja distribui presentes de Natal aos seus clientes, que consistem em uma moeda de prata ou uma moeda de ouro dependendo do total de vendas e da decisão do proprietário.

O modelo funcional para o software de atacado é fornecido abaixo. A figura abaixo mostra o DFD de nível superior. Mostra o software como um processo único e os atores que interagem com ele.

Os atores do sistema são -

  • Customers
  • Salesperson
  • Proprietor

No próximo nível DFD, conforme mostrado na figura a seguir, os principais processos do sistema são identificados, os armazenamentos de dados são definidos e a interação dos processos com os atores, e os armazenamentos de dados são estabelecidos.

No sistema, três processos podem ser identificados, que são -

  • Cadastre clientes
  • Vendas de Processo
  • Determinar presentes

Os armazenamentos de dados que serão necessários são -

  • Detalhes do cliente
  • Detalhes de Vendas
  • Detalhes do presente

A figura a seguir mostra os detalhes do processo de Cadastro de Cliente. Existem três processos nele, Verificar detalhes, Gerar C_Code e Atualizar detalhes do cliente. Quando os detalhes do cliente são inseridos, eles são verificados. Se os dados estiverem corretos, C_Code é gerado e os Dados do cliente do armazenamento de dados são atualizados.

A figura a seguir mostra a expansão do processo Determinar Presentes. Ele tem dois processos, Encontrar Vendas Totais e Decidir Tipo de Moeda de Presente. O processo Find Total Sales calcula o total anual de vendas correspondente a cada cliente e registra os dados. Tomando esse registro e a decisão do proprietário como entradas, as moedas do presente são distribuídas pelo processo Decidir o tipo de moeda do presente.

Vantagens e desvantagens do DFD

Vantagens Desvantagens
Os DFDs representam os limites de um sistema e, portanto, são úteis para retratar o relacionamento entre os objetos externos e os processos dentro do sistema. Os DFDs levam muito tempo para criar, o que pode não ser viável para fins práticos.
Eles ajudam os usuários a ter um conhecimento sobre o sistema. Os DFDs não fornecem nenhuma informação sobre o comportamento dependente do tempo, ou seja, eles não especificam quando as transformações são feitas.
A representação gráfica serve como um plano para os programadores desenvolverem um sistema. Eles não lançam nenhuma luz sobre a frequência dos cálculos ou as razões para os cálculos.
Os DFDs fornecem informações detalhadas sobre os processos do sistema. A preparação de DFDs é um processo complexo que requer especialização considerável. Além disso, é difícil para uma pessoa não técnica entender.
Eles são usados ​​como parte da documentação do sistema. O método de preparação é subjetivo e deixa muitas possibilidades para ser impreciso.

Relação entre objetos, modelos dinâmicos e funcionais

O Modelo de Objeto, o Modelo Dinâmico e o Modelo Funcional são complementares entre si para uma Análise Orientada a Objetos completa.

  • A modelagem de objetos desenvolve a estrutura estática do sistema de software em termos de objetos. Assim, mostra os “fazedores” de um sistema.

  • A Modelagem Dinâmica desenvolve o comportamento temporal dos objetos em resposta a eventos externos. Mostra as sequências de operações realizadas nos objetos.

  • O modelo funcional oferece uma visão geral do que o sistema deve fazer.

Modelo Funcional e Modelo de Objeto

As quatro partes principais de um modelo funcional em termos de modelo de objeto são -

  • Process - Os processos implicam os métodos dos objetos que precisam ser implementados.

  • Actors - Atores são os objetos no modelo de objeto.

  • Data Stores - Esses são objetos no modelo de objeto ou atributos de objetos.

  • Data Flows- Fluxos de dados para ou de atores representam operações em ou por objetos. Os fluxos de dados de ou para armazenamentos de dados representam consultas ou atualizações.

Modelo Funcional e Modelo Dinâmico

O modelo dinâmico indica quando as operações são realizadas, enquanto o modelo funcional indica como elas são realizadas e quais argumentos são necessários. Como os atores são objetos ativos, o modelo dinâmico deve especificar quando atua. Os armazenamentos de dados são objetos passivos e respondem apenas a atualizações e consultas; portanto, o modelo dinâmico não precisa especificar quando eles atuam.

Modelo de objeto e modelo dinâmico

O modelo dinâmico mostra o estado dos objetos e as operações realizadas nas ocorrências de eventos e as alterações subsequentes de estados. O estado do objeto como resultado das mudanças é mostrado no modelo de objeto.

A Unified Modeling Language (UML) é uma linguagem gráfica para OOAD que fornece uma maneira padrão de escrever um projeto de sistema de software. Ajuda a visualizar, especificar, construir e documentar os artefatos de um sistema orientado a objetos. É usado para representar as estruturas e os relacionamentos em um sistema complexo.

Breve história

Foi desenvolvido na década de 1990 como um amálgama de várias técnicas, com destaque a técnica OOAD de Grady Booch, OMT (Object Modeling Technique) de James Rumbaugh e OOSE (Object Oriented Software Engineering) de Ivar Jacobson. A UML tentou padronizar modelos semânticos, notações sintáticas e diagramas de OOAD.

Sistemas e modelos em UML

System- Um conjunto de elementos organizados para atingir certos objetivos formam um sistema. Os sistemas são freqüentemente divididos em subsistemas e descritos por um conjunto de modelos.

Model - O modelo é uma abstração simplificada, completa e consistente de um sistema, criada para melhor compreensão do sistema.

View - Uma visão é uma projeção do modelo de um sistema de uma perspectiva específica.

Modelo Conceitual de UML

O modelo conceitual de UML abrange três elementos principais -

  • Blocos de construção básicos
  • Rules
  • Mecanismos comuns

Blocos de construção básicos

Os três blocos de construção da UML são -

  • Things
  • Relationships
  • Diagrams

Coisas

Existem quatro tipos de coisas em UML, a saber -

  • Structural Things- Esses são os substantivos dos modelos UML que representam os elementos estáticos que podem ser físicos ou conceituais. As coisas estruturais são classe, interface, colaboração, caso de uso, classe ativa, componentes e nós.

  • Behavioral Things- Esses são os verbos dos modelos UML que representam o comportamento dinâmico no tempo e no espaço. Os dois tipos de coisas comportamentais são interação e máquina de estado.

  • Grouping Things- Eles compreendem as partes organizacionais dos modelos UML. Existe apenas um tipo de agrupamento, isto é, pacote.

  • Annotational Things - Estas são as explicações nos modelos UML que representam os comentários aplicados para descrever os elementos.

Relacionamentos

Relacionamentos são a conexão entre as coisas. Os quatro tipos de relacionamentos que podem ser representados em UML são -

  • Dependency- Essa é uma relação semântica entre duas coisas, de modo que uma mudança em uma coisa acarreta uma mudança na outra. A primeira é a coisa independente, enquanto a última é a coisa dependente.

  • Association - Esta é uma relação estrutural que representa um grupo de elos com estrutura e comportamento comuns.

  • Generalization - Isso representa um relacionamento de generalização / especialização no qual as subclasses herdam a estrutura e o comportamento das superclasses.

  • Realization - Esta é uma relação semântica entre dois ou mais classificadores, de forma que um classificador estabelece um contrato que os outros classificadores garantem cumprir.

Diagramas

Um diagrama é uma representação gráfica de um sistema. É composto por um grupo de elementos geralmente na forma de um gráfico. UML inclui nove diagramas ao todo, a saber -

  • Diagrama de Classe
  • Diagrama de Objeto
  • Diagrama de casos de uso
  • Diagrama de sequência
  • Diagrama de Colaboração
  • Diagrama de gráfico de estado
  • Diagrama de atividades
  • Diagrama de Componentes
  • Diagrama de implantação

Regras

A UML tem uma série de regras para que os modelos sejam semanticamente autoconsistentes e relacionados a outros modelos no sistema de maneira harmoniosa. UML tem regras semânticas para o seguinte -

  • Names
  • Scope
  • Visibility
  • Integrity
  • Execution

Mecanismos Comuns

UML tem quatro mecanismos comuns -

  • Specifications
  • Adornments
  • Divisões Comuns
  • Mecanismos de extensibilidade

Especificações

Na UML, por trás de cada notação gráfica, há uma instrução textual que denota a sintaxe e a semântica. Estas são as especificações. As especificações fornecem um backplane semântico que contém todas as partes de um sistema e o relacionamento entre os diferentes caminhos.

Adornos

Cada elemento em UML possui uma notação gráfica exclusiva. Além disso, existem notações para representar os aspectos importantes de um elemento como nome, escopo, visibilidade, etc.

Divisões Comuns

Os sistemas orientados a objetos podem ser divididos de várias maneiras. As duas formas comuns de divisão são -

  • Division of classes and objects- Uma classe é uma abstração de um grupo de objetos semelhantes. Um objeto é a instância concreta que tem existência real no sistema.

  • Division of Interface and Implementation- Uma interface define as regras de interação. A implementação é a realização concreta das regras definidas na interface.

Mecanismos de extensibilidade

UML é uma linguagem aberta. É possível estender os recursos da UML de maneira controlada para atender aos requisitos de um sistema. Os mecanismos de extensibilidade são -

  • Stereotypes - Estende o vocabulário da UML, por meio do qual novos blocos de construção podem ser criados a partir dos existentes.

  • Tagged Values - Estende as propriedades dos blocos de construção UML.

  • Constraints - Estende a semântica dos blocos de construção UML.

UML define notações específicas para cada um dos blocos de construção.

Classe

Uma classe é representada por um retângulo com três seções -

  • a seção superior contendo o nome da classe
  • a seção intermediária contendo atributos de classe
  • a seção inferior que representa as operações da classe

A visibilidade dos atributos e operações pode ser representada das seguintes maneiras -

  • Public- Um membro público é visível de qualquer lugar no sistema. No diagrama de classes, é prefixado pelo símbolo '+'.

  • Private- Um membro particular é visível apenas de dentro da classe. Não pode ser acessado de fora da classe. Um membro privado é prefixado pelo símbolo '-'.

  • Protected- Um membro protegido é visível de dentro da classe e das subclasses herdadas dessa classe, mas não de fora. É prefixado pelo símbolo '#'.

Uma classe abstrata tem o nome da classe escrito em itálico.

Example- Vamos considerar a classe Circle apresentada anteriormente. Os atributos de Círculo são coord x, coord y e raio. As operações são findArea (), findCircumference () e scale (). Vamos supor que x-coord ey-coord são membros de dados privados, radius é um membro de dados protegido e as funções de membro são públicas. A figura a seguir fornece a representação esquemática da classe.

Objeto

Um objeto é representado como um retângulo com duas seções -

  • A seção superior contém o nome do objeto com o nome da classe ou pacote do qual é uma instância. O nome assume as seguintes formas -

    • object-name - nome da classe

    • object-name - class-name :: package-name

    • class-name - no caso de objetos anônimos

  • A seção inferior representa os valores dos atributos. Ele assume o formato nome-do-atributo = valor.

  • Às vezes, os objetos são representados por meio de retângulos arredondados.

Example- Consideremos um objeto da classe Circle denominado c1. Assumimos que o centro de c1 está em (2, 3) e o raio de c1 é 5. A figura a seguir descreve o objeto.

Componente

Um componente é uma parte física e substituível do sistema que está em conformidade e fornece a realização de um conjunto de interfaces. Ele representa o empacotamento físico de elementos como classes e interfaces.

Notation - Em diagramas UML, um componente é representado por um retângulo com guias, conforme mostrado na figura abaixo.

Interface

Interface é uma coleção de métodos de uma classe ou componente. Ele especifica o conjunto de serviços que podem ser fornecidos pela classe ou componente.

Notation- Geralmente, uma interface é desenhada como um círculo junto com seu nome. Uma interface quase sempre está anexada à classe ou componente que a realiza. A figura a seguir fornece a notação de uma interface.

Pacote

Um pacote é um grupo organizado de elementos. Um pacote pode conter coisas estruturais como classes, componentes e outros pacotes.

Notation- Graficamente, um pacote é representado por uma pasta com guias. Um pacote geralmente é desenhado apenas com seu nome. No entanto, pode conter detalhes adicionais sobre o conteúdo da embalagem. Veja as figuras a seguir.

Relação

As notações para os diferentes tipos de relacionamentos são as seguintes -

Normalmente, os elementos de um relacionamento desempenham papéis específicos no relacionamento. Um nome de função significa o comportamento de um elemento que participa de um determinado contexto.

Example- As figuras a seguir mostram exemplos de diferentes relacionamentos entre classes. A primeira figura mostra uma associação entre duas classes, Departamento e Funcionário, em que um departamento pode ter vários funcionários trabalhando nele. Worker é o nome da função. O '1' ao lado do Departamento e '*' ao lado do Funcionário mostram que a razão de cardinalidade é de um para muitos. A segunda figura retrata a relação de agregação, uma Universidade é o “todo” de muitos departamentos.

Os diagramas estruturais UML são categorizados da seguinte maneira: diagrama de classes, diagrama de objetos, diagrama de componentes e diagrama de implantação.

Diagrama de Classe

Um diagrama de classes modela a visão estática de um sistema. Compreende as classes, interfaces e colaborações de um sistema; e as relações entre eles.

Diagrama de classes de um sistema

Vamos considerar um sistema bancário simplificado.

Um banco tem muitas agências. Em cada zona, uma agência é designada como a sede zonal que supervisiona as outras agências naquela zona. Cada filial pode ter várias contas e empréstimos. Uma conta pode ser uma conta poupança ou uma conta corrente. Um cliente pode abrir uma conta poupança e uma conta corrente. No entanto, o cliente não deve ter mais de uma conta poupança ou conta corrente. Um cliente também pode obter empréstimos do banco.

A figura a seguir mostra o diagrama de classe correspondente.

Aulas no sistema

Banco, agência, conta, conta poupança, conta corrente, empréstimo e cliente.

Relacionamentos

  • A Bank “has–a” number of Branches - composição, um para muitos

  • A Branch with role Zonal Head Office supervises other Branches - associação unária, um para muitos

  • A Branch “has–a” number of accounts - agregação, um para muitos

Da classe Conta, duas classes herdaram, a saber, Conta Poupança e Conta Corrente.

  • A Customer can have one Current Account - associação, um para um

  • A Customer can have one Savings Account - associação, um para um

  • A Branch “has–a” number of Loans - agregação, um para muitos

  • A Customer can take many loans - associação, um para muitos

Diagrama de Objeto

Um diagrama de objetos modela um grupo de objetos e seus links em um determinado momento. Ele mostra as instâncias das coisas em um diagrama de classes. O diagrama de objetos é a parte estática de um diagrama de interação.

Example - A figura a seguir mostra um diagrama de objeto de uma parte do diagrama de classes do Sistema Bancário.

Diagrama de Componentes

Os diagramas de componentes mostram a organização e as dependências entre um grupo de componentes.

Os diagramas de componentes são compostos por -

  • Components
  • Interfaces
  • Relationships
  • Pacotes e subsistemas (opcional)

Os diagramas de componentes são usados ​​para -

  • construção de sistemas por meio de engenharia direta e reversa.

  • modelagem de gerenciamento de configuração de arquivos de código-fonte durante o desenvolvimento de um sistema usando uma linguagem de programação orientada a objetos.

  • representando esquemas em bancos de dados de modelagem.

  • modelagem de comportamentos de sistemas dinâmicos.

Example

A figura a seguir mostra um diagrama de componentes para modelar o código-fonte de um sistema desenvolvido em C ++. Ele mostra quatro arquivos de código-fonte, a saber, myheader.h, otherheader.h, priority.cpp e other.cpp. Duas versões de myheader.h são mostradas, rastreando desde a versão recente até seu ancestral. O arquivo priority.cpp tem dependência de compilação em other.cpp. O arquivo other.cpp tem dependência de compilação em otherheader.h.

Diagrama de implantação

Um diagrama de implantação enfatiza a configuração dos nós de processamento de tempo de execução e seus componentes que residem neles. Eles geralmente são compostos de nós e dependências ou associações entre os nós.

Os diagramas de implantação são usados ​​para -

  • dispositivos modelo em sistemas embarcados que normalmente consistem em uma coleção de hardware com uso intensivo de software.

  • representam as topologias de sistemas cliente / servidor.

  • modelo de sistemas totalmente distribuídos.

Example

A figura a seguir mostra a topologia de um sistema de computador que segue a arquitetura cliente / servidor. A figura ilustra um nó estereotipado como servidor que é composto por processadores. A figura indica que quatro ou mais servidores estão implantados no sistema. Conectados ao servidor estão os nós clientes, onde cada nó representa um dispositivo terminal, como estação de trabalho, laptop, scanner ou impressora. Os nós são representados por ícones que representam claramente o equivalente no mundo real.

Os diagramas UML comportamentais visualizam, especificam, constroem e documentam os aspectos dinâmicos de um sistema. Os diagramas comportamentais são categorizados da seguinte maneira: diagramas de caso de uso, diagramas de interação, diagramas de estado-gráfico e diagramas de atividades.

Modelo de caso de uso

Caso de uso

Um caso de uso descreve a sequência de ações que um sistema executa produzindo resultados visíveis. Mostra a interação de coisas fora do sistema com o próprio sistema. Os casos de uso podem ser aplicados a todo o sistema, bem como a uma parte do sistema.

Ator

Um ator representa as funções que os usuários dos casos de uso desempenham. Um ator pode ser uma pessoa (por exemplo, estudante, cliente), um dispositivo (por exemplo, estação de trabalho) ou outro sistema (por exemplo, banco, instituição).

A figura a seguir mostra as notações de um ator denominado Aluno e um caso de uso denominado Gerar Relatório de Desempenho.

Diagramas de caso de uso

Os diagramas de caso de uso apresentam uma visão externa da maneira como os elementos em um sistema se comportam e como podem ser usados ​​no contexto.

Os diagramas de caso de uso são compostos por -

  • Casos de uso
  • Actors
  • Relacionamentos como dependência, generalização e associação

Diagramas de caso de uso são usados ​​-

  • Modelar o contexto de um sistema encerrando todas as atividades de um sistema em um retângulo e focalizando os atores externos ao sistema, interagindo com ele.

  • Modelar os requisitos de um sistema do ponto de vista externo.

Example

Vamos considerar um sistema automatizado de trading house. Assumimos as seguintes características do sistema -

  • A trading tem transações com dois tipos de clientes, clientes individuais e clientes corporativos.

  • Depois que o cliente faz um pedido, ele é processado pelo departamento de vendas e o cliente recebe a fatura.

  • O sistema permite que o gerente gerencie as contas dos clientes e responda às dúvidas postadas pelo cliente.

Diagramas de interação

Os diagramas de interação representam as interações dos objetos e seus relacionamentos. Eles também incluem as mensagens trocadas entre eles. Existem dois tipos de diagramas de interação -

  • Diagramas de Seqüência
  • Diagramas de Colaboração

Diagramas de interação são usados ​​para modelagem -

  • o fluxo de controle por ordenação de tempo usando diagramas de seqüência.

  • o fluxo de controle da organização usando diagramas de colaboração.

Diagramas de Seqüência

Os diagramas de sequência são diagramas de interação que ilustram a ordem das mensagens de acordo com o tempo.

Notations- Esses diagramas têm a forma de gráficos bidimensionais. Os objetos que iniciam a interação são colocados no eixo x. As mensagens que esses objetos enviam e recebem são colocadas ao longo do eixo y, em ordem crescente de tempo de cima para baixo.

Example - Um diagrama de sequência para o Sistema Automated Trading House é mostrado na figura a seguir.

Diagramas de Colaboração

Os diagramas de colaboração são diagramas de interação que ilustram a estrutura dos objetos que enviam e recebem mensagens.

Notations- Nestes diagramas, os objetos que participam da interação são mostrados por meio de vértices. Os links que conectam os objetos são usados ​​para enviar e receber mensagens. A mensagem é mostrada como uma seta marcada.

Example - O diagrama de colaboração para o Automated Trading House System é ilustrado na figura abaixo.

Diagramas de estado-gráfico

Um diagrama de gráfico de estado mostra uma máquina de estado que descreve o fluxo de controle de um objeto de um estado para outro. Uma máquina de estado retrata as sequências de estados pelos quais um objeto passa devido a eventos e suas respostas a eventos.

Os diagramas de estado-gráfico são compostos por -

  • Estados: Simples ou Composto
  • Transições entre estados
  • Eventos que causam transições
  • Ações devido aos eventos

Os diagramas de gráfico de estado são usados ​​para modelar objetos que são reativos por natureza.

Example

No Automated Trading House System, vamos modelar a Ordem como um objeto e rastrear sua sequência. A figura a seguir mostra o diagrama de gráfico de estado correspondente.

Diagramas de Atividades

Um diagrama de atividades descreve o fluxo de atividades que são operações não atômicas em andamento em uma máquina de estado. As atividades resultam em ações que são operações atômicas.

Os diagramas de atividades são compostos por -

  • Estados de atividade e estados de ação
  • Transitions
  • Objects

Diagramas de atividades são usados ​​para modelagem -

  • fluxos de trabalho vistos pelos atores, interagindo com o sistema.
  • detalhes de operações ou cálculos usando fluxogramas.

Example

A figura a seguir mostra um diagrama de atividades de uma parte do Automated Trading House System.

Após a fase de análise, o modelo conceitual é desenvolvido em um modelo orientado a objetos usando design orientado a objetos (OOD). No OOD, os conceitos independentes de tecnologia no modelo de análise são mapeados em classes de implementação, as restrições são identificadas e as interfaces são projetadas, resultando em um modelo para o domínio da solução. Em suma, uma descrição detalhada é construída especificando como o sistema deve ser construído em tecnologias concretas

Os estágios do design orientado a objetos podem ser identificados como -

  • Definição do contexto do sistema
  • Projetando a arquitetura do sistema
  • Identificação dos objetos no sistema
  • Construção de modelos de design
  • Especificação de interfaces de objetos

Projeto de sistema

O projeto de sistema orientado a objetos envolve a definição do contexto de um sistema, seguido pelo projeto da arquitetura do sistema.

  • Context- O contexto de um sistema tem uma parte estática e outra dinâmica. O contexto estático do sistema é projetado usando um diagrama de blocos simples de todo o sistema, que é expandido em uma hierarquia de subsistemas. O modelo de subsistema é representado por pacotes UML. O contexto dinâmico descreve como o sistema interage com seu ambiente. É modelado usandouse case diagrams.

  • System Architecture- A arquitetura do sistema é projetada com base no contexto do sistema de acordo com os princípios do projeto de arquitetura e também do conhecimento do domínio. Normalmente, um sistema é particionado em camadas e cada camada é decomposta para formar os subsistemas.

Decomposição Orientada a Objetos

Decomposição significa dividir um grande sistema complexo em uma hierarquia de componentes menores com complexidades menores, com base nos princípios de dividir e conquistar. Cada componente principal do sistema é chamado de subsistema. A decomposição orientada a objetos identifica objetos autônomos individuais em um sistema e a comunicação entre esses objetos.

As vantagens da decomposição são -

  • Os componentes individuais são de menor complexidade e, portanto, mais compreensíveis e gerenciáveis.

  • Permite a divisão da força de trabalho com habilidades especializadas.

  • Ele permite que subsistemas sejam substituídos ou modificados sem afetar outros subsistemas.

Identificando Simultaneidade

A simultaneidade permite que mais de um objeto receba eventos ao mesmo tempo e mais de uma atividade seja executada simultaneamente. A simultaneidade é identificada e representada no modelo dinâmico.

Para habilitar a simultaneidade, cada elemento simultâneo é atribuído a um thread de controle separado. Se a simultaneidade estiver no nível do objeto, dois objetos simultâneos serão atribuídos a dois threads de controle diferentes. Se duas operações de um único objeto são simultâneas por natureza, esse objeto é dividido entre diferentes threads.

A simultaneidade está associada a problemas de integridade de dados, deadlock e privação. Portanto, uma estratégia clara precisa ser feita sempre que a simultaneidade for necessária. Além disso, a simultaneidade deve ser identificada no próprio estágio de design e não pode ser deixada para o estágio de implementação.

Identificando Padrões

Ao projetar aplicativos, algumas soluções comumente aceitas são adotadas para algumas categorias de problemas. Esses são os padrões de design. Um padrão pode ser definido como um conjunto documentado de blocos de construção que podem ser usados ​​em certos tipos de problemas de desenvolvimento de aplicativos.

Alguns padrões de design comumente usados ​​são -

  • Padrão de fachada
  • Padrão de separação de visualização de modelo
  • Padrão do observador
  • Padrão de controlador de visualização de modelo
  • Publicar padrão de assinatura
  • Padrão proxy

Controle de eventos

Durante o projeto do sistema, os eventos que podem ocorrer nos objetos do sistema precisam ser identificados e adequadamente tratados.

Um evento é uma especificação de uma ocorrência significativa que tem uma localização no tempo e no espaço.

Existem quatro tipos de eventos que podem ser modelados, a saber -

  • Signal Event - Um objeto nomeado lançado por um objeto e pego por outro objeto.

  • Call Event - Um evento síncrono que representa o despacho de uma operação.

  • Time Event - Um evento que representa a passagem do tempo.

  • Change Event - Um evento que representa mudança de estado.

Condições de limite de manuseio

A fase de design do sistema precisa abordar a inicialização e o encerramento do sistema como um todo, bem como de cada subsistema. Os diferentes aspectos documentados são os seguintes -

  • A inicialização do sistema, ou seja, a transição do sistema do estado não inicializado para o estado estacionário.

  • O encerramento do sistema, ou seja, o encerramento de todos os threads em execução, limpeza de recursos e as mensagens a serem enviadas.

  • A configuração inicial do sistema e a reconfiguração do sistema quando necessário.

  • Prevenção de falhas ou encerramento indesejado do sistema.

As condições de limite são modeladas usando casos de uso de limite.

Projeto de Objeto

Após o desenvolvimento da hierarquia dos subsistemas, os objetos do sistema são identificados e seus detalhes projetados. Aqui, o designer detalha a estratégia escolhida durante o design do sistema. A ênfase muda de conceitos de domínio de aplicativo para conceitos de computador. Os objetos identificados durante a análise são gravados para implementação com o objetivo de minimizar o tempo de execução, o consumo de memória e o custo geral.

O design do objeto inclui as seguintes fases -

  • Identificação de objeto
  • Representação de objeto, ou seja, construção de modelos de design
  • Classificação das operações
  • Projeto de algoritmo
  • Desenho de relacionamentos
  • Implementação de controle para interações externas
  • Classes de pacotes e associações em módulos

Identificação de Objeto

A primeira etapa do projeto do objeto é a identificação do objeto. Os objetos identificados nas fases de análise orientada a objetos são agrupados em classes e refinados para que sejam adequados para implementação real.

As funções deste estágio são -

  • Identificar e refinar as classes em cada subsistema ou pacote

  • Definindo os links e associações entre as classes

  • Desenhar as associações hierárquicas entre as classes, ou seja, a generalização / especialização e as heranças

  • Projetando agregações

Representação de Objeto

Uma vez que as classes são identificadas, elas precisam ser representadas usando técnicas de modelagem de objetos. Este estágio envolve essencialmente a construção de diagramas UML.

Existem dois tipos de modelos de design que precisam ser produzidos -

  • Static Models - Descrever a estrutura estática de um sistema usando diagramas de classes e diagramas de objetos.

  • Dynamic Models - Descrever a estrutura dinâmica de um sistema e mostrar a interação entre classes usando diagramas de interação e diagramas de estado-gráfico.

Classificação das Operações

Nesta etapa, as operações a serem realizadas nos objetos são definidas pela combinação dos três modelos desenvolvidos na fase OOA, a saber, modelo de objeto, modelo dinâmico e modelo funcional. Uma operação especifica o que deve ser feito e não como deve ser feito.

As seguintes tarefas são realizadas em relação às operações -

  • O diagrama de transição de estado de cada objeto no sistema é desenvolvido.

  • As operações são definidas para os eventos recebidos pelos objetos.

  • Casos em que um evento dispara outros eventos no mesmo objeto ou em objetos diferentes são identificados.

  • As suboperações dentro das ações são identificadas.

  • As principais ações são expandidas para diagramas de fluxo de dados.

Projeto de Algoritmo

As operações nos objetos são definidas por meio de algoritmos. Um algoritmo é um procedimento passo a passo que resolve o problema estabelecido em uma operação. Os algoritmos se concentram em como isso deve ser feito.

Pode haver mais de um algoritmo correspondente a uma determinada operação. Uma vez que os algoritmos alternativos são identificados, o algoritmo ótimo é selecionado para o domínio de problema dado. As métricas para escolher o algoritmo ideal são -

  • Computational Complexity - A complexidade determina a eficiência de um algoritmo em termos de tempo de computação e requisitos de memória.

  • Flexibility - A flexibilidade determina se o algoritmo escolhido pode ser implementado adequadamente, sem perda de adequação em vários ambientes.

  • Understandability - Isso determina se o algoritmo escolhido é fácil de entender e implementar.

Desenho de Relacionamentos

A estratégia para implementar os relacionamentos precisa ser definida durante a fase de design do objeto. Os principais relacionamentos tratados incluem associações, agregações e heranças.

O designer deve fazer o seguinte em relação às associações -

  • Identifique se uma associação é unidirecional ou bidirecional.

  • Analise o caminho das associações e atualize-as se necessário.

  • Implemente as associações como um objeto distinto, no caso de relacionamentos muitos para muitos; ou como um link para outro objeto no caso de relacionamentos um-para-um ou um-para-muitos.

Em relação às heranças, o designer deve fazer o seguinte -

  • Ajuste as classes e suas associações.

  • Identifique classes abstratas.

  • Faça provisões para que os comportamentos sejam compartilhados quando necessário.

Implementação de Controle

O designer de objetos pode incorporar refinamentos na estratégia do modelo de gráfico de estado. No projeto do sistema, uma estratégia básica para realizar o modelo dinâmico é feita. Durante o projeto do objeto, essa estratégia é adequadamente embelezada para uma implementação apropriada.

As abordagens para implementação do modelo dinâmico são -

  • Represent State as a Location within a Program- Esta é a abordagem orientada por procedimento tradicional em que a localização do controle define o estado do programa. Uma máquina de estado finito pode ser implementada como um programa. Uma transição forma uma instrução de entrada, o caminho de controle principal forma a sequência de instruções, os ramos formam as condições e os caminhos de retorno formam os loops ou iterações.

  • State Machine Engine- Esta abordagem representa diretamente uma máquina de estado por meio de uma classe de mecanismo de máquina de estado. Essa classe executa a máquina de estado por meio de um conjunto de transições e ações fornecidas pelo aplicativo.

  • Control as Concurrent Tasks- Nesta abordagem, um objeto é implementado como uma tarefa na linguagem de programação ou no sistema operacional. Aqui, um evento é implementado como uma chamada entre tarefas. Ele preserva a simultaneidade inerente de objetos reais.

Aulas de embalagem

Em qualquer grande projeto, o particionamento meticuloso de uma implementação em módulos ou pacotes é importante. Durante o design do objeto, classes e objetos são agrupados em pacotes para permitir que vários grupos trabalhem cooperativamente em um projeto.

Os diferentes aspectos da embalagem são -

  • Hiding Internal Information from Outside View - Permite que uma classe seja vista como uma “caixa preta” e permite que a implementação da classe seja alterada sem exigir que nenhum cliente da classe modifique o código.

  • Coherence of Elements - Um elemento, como uma classe, uma operação ou um módulo, é coerente se for organizado em um plano consistente e todas as suas partes estiverem intrinsecamente relacionadas para servir a um objetivo comum.

  • Construction of Physical Modules - As seguintes diretrizes ajudam na construção de módulos físicos -

    • As classes em um módulo devem representar coisas ou componentes semelhantes no mesmo objeto composto.

    • As classes estreitamente conectadas devem estar no mesmo módulo.

    • Classes desconectadas ou fracamente conectadas devem ser colocadas em módulos separados.

    • Os módulos devem ter boa coesão, ou seja, alta cooperação entre seus componentes.

    • Um módulo deve ter baixo acoplamento com outros módulos, ou seja, a interação ou interdependência entre os módulos deve ser mínima.

Otimização de Design

O modelo de análise captura as informações lógicas sobre o sistema, enquanto o modelo de design adiciona detalhes para oferecer suporte ao acesso eficiente às informações. Antes de um design ser implementado, ele deve ser otimizado para tornar a implementação mais eficiente. O objetivo da otimização é minimizar o custo em termos de tempo, espaço e outras métricas.

No entanto, a otimização do design não deve ser excessiva, pois facilidade de implementação, facilidade de manutenção e extensibilidade também são preocupações importantes. É comum ver que um design perfeitamente otimizado é mais eficiente, mas menos legível e reutilizável. Portanto, o designer deve encontrar um equilíbrio entre os dois.

As várias coisas que podem ser feitas para a otimização do design são -

  • Adicionar associações redundantes
  • Omitir associações não utilizáveis
  • Otimização de algoritmos
  • Salve atributos derivados para evitar o recálculo de expressões complexas

Adição de Associações Redundantes

Durante a otimização do projeto, é verificado se a derivação de novas associações pode reduzir os custos de acesso. Embora essas associações redundantes possam não adicionar nenhuma informação, elas podem aumentar a eficiência do modelo geral.

Omissão de associações não utilizáveis

A presença de muitas associações pode tornar um sistema indecifrável e, portanto, reduzir a eficiência geral do sistema. Portanto, durante a otimização, todas as associações não utilizáveis ​​são removidas.

Otimização de Algoritmos

Em sistemas orientados a objetos, a otimização da estrutura de dados e algoritmos é feita de forma colaborativa. Uma vez que o design da classe esteja estabelecido, as operações e os algoritmos precisam ser otimizados.

A otimização de algoritmos é obtida por -

  • Reorganização da ordem das tarefas computacionais
  • Reversão da ordem de execução de loops daquela estabelecida no modelo funcional
  • Remoção de caminhos mortos dentro do algoritmo

Salvar e armazenar atributos derivados

Atributos derivados são aqueles atributos cujos valores são calculados em função de outros atributos (atributos básicos). O recálculo dos valores dos atributos derivados sempre que eles são necessários é um procedimento demorado. Para evitar isso, os valores podem ser calculados e armazenados em suas formas calculadas.

No entanto, isso pode representar anomalias de atualização, ou seja, uma mudança nos valores dos atributos de base sem mudança correspondente nos valores dos atributos derivados. Para evitar isso, as seguintes etapas são executadas -

  • Com cada atualização do valor do atributo básico, o atributo derivado também é recalculado.

  • Todos os atributos derivados são recalculados e atualizados periodicamente em um grupo, em vez de após cada atualização.

Documentação de Design

A documentação é uma parte essencial de qualquer processo de desenvolvimento de software que registre o procedimento de fabricação do software. As decisões de design precisam ser documentadas para qualquer sistema de software não trivial para transmitir o design a outros.

Áreas de Uso

Embora seja um produto secundário, uma boa documentação é indispensável, principalmente nas seguintes áreas -

  • No design de software que está sendo desenvolvido por vários desenvolvedores
  • Em estratégias iterativas de desenvolvimento de software
  • No desenvolvimento de versões subsequentes de um projeto de software
  • Para avaliar um software
  • Para encontrar condições e áreas de teste
  • Para manutenção do software.

Conteúdo

Uma documentação benéfica deve essencialmente incluir o seguinte conteúdo -

  • High–level system architecture - Diagramas de processo e diagramas de módulo

  • Key abstractions and mechanisms - Diagramas de classes e diagramas de objetos.

  • Scenarios that illustrate the behavior of the main aspects - Diagramas comportamentais

Características

As características de uma boa documentação são -

  • Conciso e, ao mesmo tempo, inequívoco, consistente e completo

  • Rastreável às especificações de requisitos do sistema

  • Well-structured

  • Esquemático em vez de descritivo

A implementação de um projeto orientado a objetos geralmente envolve o uso de uma linguagem de programação orientada a objetos (OOPL) padrão ou o mapeamento de projetos de objetos para bancos de dados. Na maioria dos casos, envolve ambos.

Implementação usando linguagens de programação

Normalmente, a tarefa de transformar o design de um objeto em código é um processo direto. Qualquer linguagem de programação orientada a objetos, como C ++, Java, Smalltalk, C # e Python, inclui provisão para representar classes. Neste capítulo, exemplificamos o conceito usando C ++.

A figura a seguir mostra a representação da classe Circle usando C ++.

Implementando Associações

A maioria das linguagens de programação não fornece construções para implementar associações diretamente. Portanto, a tarefa de implementar associações requer uma reflexão considerável.

As associações podem ser unidirecionais ou bidirecionais. Além disso, cada associação pode ser um para um, um para muitos ou muitos para muitos.

Associações Unidirecionais

Para implementar associações unidirecionais, deve-se tomar cuidado para que a unidirecionalidade seja mantida. As implementações para diferentes multiplicidades são as seguintes -

  • Optional Associations- Aqui, um link pode ou não existir entre os objetos participantes. Por exemplo, na associação entre Cliente e Conta Corrente na figura abaixo, um cliente pode ou não ter uma conta corrente.

Para implementação, um objeto de Conta Atual é incluído como um atributo em Cliente que pode ser NULO. Implementação usando C ++ -

class Customer {
   private:
   // attributes
   Current_Account c; //an object of Current_Account as attribute
   
   public:  

   Customer() {
      c = NULL; 
   } // assign c as NULL

   Current_Account getCurrAc() {
      return c;
   }
   
   void setCurrAc( Current_Account myacc) {
      c = myacc;
   }

   void removeAcc() {  
      c = NULL;
   } 
};
  • One–to–one Associations- Aqui, uma instância de uma classe está relacionada a exatamente uma instância da classe associada. Por exemplo, Departamento e Gerente têm associação um para um, conforme mostrado na figura abaixo.

Isso é implementado incluindo no Departamento, um objeto de Gerente que não deve ser NULL. Implementação usando C ++ -

class Department {
   private:
   // attributes
   Manager mgr; //an object of Manager as attribute
   
   public:  
   Department (/*parameters*/, Manager m) { //m is not NULL   
      // assign parameters to variables
      mgr = m;
   } 

   Manager getMgr() {  
      return mgr;  
   }    
};
  • One–to–many Associations- Aqui, uma instância de uma classe está relacionada a mais de uma instância da classe associada. Por exemplo, considere a associação entre Funcionário e Dependente na figura a seguir.

Isso é implementado incluindo uma lista de Dependentes na classe Employee. Implementação usando o contêiner de lista C ++ STL -

class Employee {
   private:
   char * deptName;
   list <Dependent> dep; //a list of Dependents as attribute

   public:  
   void addDependent ( Dependent d) { 
      dep.push_back(d); 
   } // adds an employee to the department

   void removeDeoendent( Dependent d) { 
      int index = find ( d, dep );
      // find() function returns the index of d in list dep
      dep.erase(index);
   }               
};

Associações bidirecionais

Para implementar a associação bidirecional, os links em ambas as direções precisam ser mantidos.

  • Optional or one–to–one Associations - Considere a relação entre o Projeto e o Gerente de Projeto tendo uma associação bidirecional um para um, conforme mostrado na figura abaixo.

Implementação usando C ++ -

Class Project {
   private:
   // attributes
   Project_Manager pmgr; 
   public:  
   void setManager ( Project_Manager pm);       
   Project_Manager changeManager();   
};

class Project_Manager {
   private:
   // attributes
   Project pj; 

   public:  
   void setProject(Project p);       
   Project removeProject();   
};
  • One–to–many Associations - Considere a relação entre o Departamento e o Funcionário tendo uma associação de um para muitos, conforme mostrado na figura abaixo.

Implementação usando o contêiner de lista C ++ STL

class Department {
   private:
   char * deptName;
   list <Employee> emp; //a list of Employees as attribute

   public:  
   void addEmployee ( Employee e) { 
      emp.push_back(e); 
   } // adds an employee to the department

   void removeEmployee( Employee e) { 
      int index = find ( e, emp );
      // find function returns the index of e in list emp
      emp.erase(index);
   }               
};

class Employee {
   private:
   //attributes
   Department d;

   public:
   void addDept();
   void removeDept();
};

Implementando Associações como Classes

Se uma associação tiver alguns atributos associados, ela deve ser implementada usando uma classe separada. Por exemplo, considere a associação um para um entre Funcionário e Projeto, conforme mostrado na figura abaixo.

Implementação de WorksOn usando C ++

class WorksOn {
   private:
   Employee e; 
   Project p;
   Hours h;
   char * date;

   public:
   // class methods
};

Implementando Restrições

As restrições nas classes restringem o intervalo e o tipo de valores que os atributos podem assumir. Para implementar restrições, um valor padrão válido é atribuído ao atributo quando um objeto é instanciado a partir da classe. Sempre que o valor é alterado em tempo de execução, é verificado se o valor é válido ou não. Um valor inválido pode ser tratado por uma rotina de tratamento de exceção ou outros métodos.

Example

Considere uma classe Employee em que idade é um atributo que pode ter valores na faixa de 18 a 60. O código C ++ a seguir o incorpora -

class Employee {
   private: char * name;
   int age;
   // other attributes

   public:
   Employee() {                 // default constructor   
      strcpy(name, "");
      age = 18;                // default value
   }
 
   class AgeError {};          // Exception class
   void changeAge( int a) {    // method that changes age

      if ( a < 18 || a > 60 )  // check for invalid condition
      throw AgeError();        // throw exception
      age = a;			
   }
};

Implementando gráficos de estado

Existem duas estratégias de implementação alternativas para implementar estados em diagramas de gráficos de estados.

Enumerações dentro da classe

Nessa abordagem, os estados são representados por diferentes valores de um membro de dados (ou conjunto de membros de dados). Os valores são definidos explicitamente por uma enumeração dentro da classe. As transições são representadas por funções de membro que alteram o valor do membro de dados em questão.

Organização de classes em uma hierarquia de generalização

Nessa abordagem, os estados são organizados em uma hierarquia de generalização de uma maneira que podem ser referidos por uma variável de ponteiro comum. A figura a seguir mostra uma transformação do diagrama de gráfico de estado em uma hierarquia de generalização.

Mapeamento de Objetos para Sistema de Banco de Dados

Persistência de Objetos

Um aspecto importante do desenvolvimento de sistemas orientados a objetos é a persistência dos dados. Por meio da persistência, os objetos têm vida útil mais longa do que o programa que os criou. Os dados persistentes são salvos no meio de armazenamento secundário de onde podem ser recarregados quando necessário.

Visão geral do RDBMS

Um banco de dados é uma coleção ordenada de dados relacionados.

Um sistema de gerenciamento de banco de dados (DBMS) é uma coleção de software que facilita os processos de definição, criação, armazenamento, manipulação, recuperação, compartilhamento e remoção de dados em bancos de dados.

Em sistemas de gerenciamento de banco de dados relacional (RDBMS), os dados são armazenados como relações ou tabelas, onde cada coluna ou campo representa um atributo e cada linha ou tupla representa um registro de uma instância.

Cada linha é identificada exclusivamente por um conjunto escolhido de atributos mínimos chamados primary key.

UMA foreign key é um atributo que é a chave primária de uma tabela relacionada.

Representando Classes como Tabelas em RDBMS

Para mapear uma classe para uma tabela de banco de dados, cada atributo é representado como um campo na tabela. Um atributo existente (s) é atribuído como uma chave primária ou um campo de ID separado é adicionado como uma chave primária. A classe pode ser particionada horizontalmente ou verticalmente de acordo com os requisitos.

Por exemplo, a classe Circle pode ser convertida em tabela, conforme mostrado na figura abaixo.

Schema for Circle Table: CIRCLE(CID, X_COORD, Y_COORD, RADIUS, COLOR)
Creating a Table Circle using SQL command:
CREATE TABLE CIRCLE (   
   CID	VARCHAR2(4) PRIMARY KEY,
   X_COORD INTEGER NOT NULL,
   Y_COORD INTEGER NOT NULL,
   Z_COORD INTEGER NOT NULL,
   COLOR 
);

Mapeamento de associações para tabelas de banco de dados

Associações Um para Um

Para implementar associações 1: 1, a chave primária de qualquer tabela é atribuída como a chave estrangeira da outra tabela. Por exemplo, considere a associação entre Departamento e Gerente -

Comandos SQL para criar as tabelas

CREATE TABLE DEPARTMENT ( 
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
   EMPID INTEGER REFERENCES MANAGER 
);

CREATE TABLE MANAGER ( 
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
);

Associações Um para Muitos

Para implementar associações 1: N, a chave primária da tabela no lado 1 da associação é atribuída como a chave estrangeira da tabela no lado N da associação. Por exemplo, considere a associação entre Departamento e Funcionário -

Comandos SQL para criar as tabelas

CREATE TABLE DEPARTMENT ( 
   DEPT_ID INTEGER PRIMARY KEY,
   DNAME VARCHAR2(30) NOT NULL,
   LOCATION VARCHAR2(20),
);

CREATE TABLE EMPLOYEE ( 
   EMPID INTEGER PRIMARY KEY,
   ENAME VARCHAR2(50) NOT NULL,
   ADDRESS VARCHAR2(70),
   D_ID INTEGER REFERENCES DEPARTMENT
);

Associações Muitos para Muitos

Para implementar associações M: N, uma nova relação é criada que representa a associação. Por exemplo, considere a seguinte associação entre Funcionário e Projeto -

Schema for Works_On Table - WORKS_ON (EMPID, PID, HOURS, START_DATE)

SQL command to create Works_On association - CRIAR TABELA WORKS_ON

( 
   EMPID INTEGER,
   PID INTEGER, 
   HOURS INTEGER,
   START_DATE DATE,
   PRIMARY KEY (EMPID, PID),
   FOREIGN KEY (EMPID) REFERENCES EMPLOYEE,
   FOREIGN KEY (PID) REFERENCES PROJECT 
);

Mapeamento de herança para tabelas

Para mapear a herança, a chave primária da (s) tabela (s) base é atribuída como a chave primária, bem como a chave estrangeira na (s) tabela (s) derivada (s).

Example

Depois que um código de programa é escrito, ele deve ser testado para detectar e, subsequentemente, tratar todos os erros nele. Vários esquemas são usados ​​para fins de teste.

Outro aspecto importante é a adequação do propósito de um programa que verifica se o programa serve ao propósito a que se destina. A aptidão define a qualidade do software.

Testando Sistemas Orientados a Objetos

O teste é uma atividade contínua durante o desenvolvimento de software. Em sistemas orientados a objetos, o teste abrange três níveis, a saber, teste de unidade, teste de subsistema e teste de sistema.

Teste de Unidade

No teste de unidade, as classes individuais são testadas. É visto se os atributos de classe são implementados de acordo com o design e se os métodos e as interfaces estão livres de erros. O teste de unidade é de responsabilidade do engenheiro de aplicação que implementa a estrutura.

Teste de subsistema

Isso envolve o teste de um determinado módulo ou subsistema e é de responsabilidade do líder do subsistema. Envolve testar as associações dentro do subsistema, bem como a interação do subsistema com o exterior. Os testes de subsistema podem ser usados ​​como testes de regressão para cada versão recém-lançada do subsistema.

Teste de Sistema

O teste do sistema envolve o teste do sistema como um todo e é responsabilidade da equipe de garantia de qualidade. A equipe costuma usar testes de sistema como testes de regressão ao montar novos lançamentos.

Técnicas de teste orientado a objetos

Teste de caixa cinza

Os diferentes tipos de casos de teste que podem ser projetados para testar programas orientados a objetos são chamados de casos de teste de caixa cinza. Alguns dos tipos importantes de teste de caixa cinza são -

  • State model based testing - Isso abrange a cobertura do estado, cobertura da transição do estado e cobertura do caminho da transição do estado.

  • Use case based testing - Cada cenário em cada caso de uso é testado.

  • Class diagram based testing - Cada classe, classe derivada, associações e agregações são testadas.

  • Sequence diagram based testing - Os métodos nas mensagens nos diagramas de seqüência são testados.

Técnicas para teste de subsistema

As duas principais abordagens de teste de subsistema são -

  • Thread based testing - Todas as classes necessárias para realizar um único caso de uso em um subsistema são integradas e testadas.

  • Use based testing- As interfaces e serviços dos módulos em cada nível de hierarquia são testados. Os testes começam nas classes individuais aos pequenos módulos compostos por classes, gradualmente aos módulos maiores e, finalmente, todos os subsistemas principais.

Categorias de teste de sistema

  • Alpha testing - Isso é realizado pela equipe de testes da organização que desenvolve o software.

  • Beta testing - Isso é realizado por um grupo seleto de clientes cooperantes.

  • Acceptance testing - Isso é realizado pelo cliente antes de aceitar as entregas.

Garantia de Qualidade de Software

Qualidade de Software

Schulmeyer e McManus definiram a qualidade do software como “a adequação para o uso do produto de software total”. Um software de boa qualidade faz exatamente o que deve fazer e é interpretado em termos de satisfação da especificação de requisitos estabelecida pelo usuário.

Garantia da Qualidade

A garantia de qualidade de software é uma metodologia que determina até que ponto um produto de software é adequado para uso. As atividades incluídas para determinar a qualidade do software são -

  • Auditing
  • Desenvolvimento de padrões e diretrizes
  • Produção de relatórios
  • Revisão do sistema de qualidade

Fatores de Qualidade

  • Correctness - A correção determina se os requisitos de software são atendidos de forma adequada.

  • Usability - A usabilidade determina se o software pode ser usado por diferentes categorias de usuários (iniciantes, não técnicos e especialistas).

  • Portability - A portabilidade determina se o software pode operar em diferentes plataformas com diferentes dispositivos de hardware.

  • Maintainability - A capacidade de manutenção determina a facilidade com que os erros podem ser corrigidos e os módulos podem ser atualizados.

  • Reusability - Reutilização determina se os módulos e classes podem ser reutilizados para desenvolver outros produtos de software.

Métricas Orientadas a Objetos

As métricas podem ser amplamente classificadas em três categorias: métricas do projeto, métricas do produto e métricas do processo.

Métricas do Projeto

As métricas do projeto permitem que um gerente de projeto de software avalie o status e o desempenho de um projeto em andamento. As seguintes métricas são apropriadas para projetos de software orientado a objetos -

  • Número de scripts de cenário
  • Número de classes principais
  • Número de aulas de apoio
  • Número de subsistemas

Métricas do Produto

As métricas do produto medem as características do produto de software que foi desenvolvido. As métricas de produto adequadas para sistemas orientados a objetos são -

  • Methods per Class- Determina a complexidade de uma aula. Se todos os métodos de uma classe forem considerados igualmente complexos, então uma classe com mais métodos é mais complexa e, portanto, mais suscetível a erros.

  • Inheritance Structure- Sistemas com várias pequenas redes de herança são mais bem estruturados do que sistemas com uma única grande rede de herança. Como regra geral, uma árvore de herança não deve ter mais de 7 (± 2) níveis e a árvore deve ser balanceada.

  • Coupling and Cohesion - Módulos de baixo acoplamento e alta coesão são considerados mais bem projetados, pois permitem maior reutilização e manutenção.

  • Response for a Class - Mede a eficiência dos métodos que são chamados pelas instâncias da classe.

Métricas de Processo

As métricas de processo ajudam a medir o desempenho de um processo. Eles são coletados em todos os projetos por longos períodos de tempo. Eles são usados ​​como indicadores para melhorias no processo de software de longo prazo. Algumas métricas de processo são -

  • Número de KLOC (Kilo Lines of Code)
  • Eficiência de remoção de defeitos
  • Número médio de falhas detectadas durante o teste
  • Número de defeitos latentes por KLOC