Notas de aula de Engenharia de Software                              (C) Jair C Leite, 2000 
Anterior | Índice | Próximo

5. Design Conceitual de Software

Neste capítulo discutiremos:

5.1 O que é design de software?

No capítulo anterior vimos como especificar os requisitos de software. Os requisitos funcionais determinam quais funções os usuários necessitam que o sistema ofereça. Vimos também como estas funções de aplicação podem ser especificadas como Casos de Usos na linguagem UML.

Para que os casos de uso tornem-se funções do software é preciso determinar como o usuário irá interagir com elas e como elas devem ser implementadas em um programa. Por exemplo, vamos considerar que o cálculo do lucro de venda é um caso de uso que faz parte dos requisitos funcionais de um sistema comercial qualquer. O caso de uso deve descrever, por exemplo, que o usuário deve fornecer o valor de compra e o valor de venda, acionar a função de cálculo e o sistema deve então fornecer o resultado calculado. Para que este (e outros) caso de uso seja concretizado numa função de aplicação do software é preciso projetar e implementar como os usuários fornecerão os valores e obterão os resultados e quais são os algoritmos que realizam tudo isto. No capítulo 1, mostramos o exemplo de um software bastante simples para o cálculo do lucro de vendas. Lá apresentamos como este caso de uso ocorre num software descrevendo a interface com a qual o usuário deve interagir e o algoritmo que implementa este programa.

A partir de agora vamos começar a estudar como a especificação de requisitos pode ser transformada na especificação do software. Devemos determinar como casos de uso devem ser transformados em funções da aplicação com as quais os usuários possam interagir e que possam ser implementadas através de uma linguagem de programação.  A esta atividade de criar o software que satisfaz os requisitos dos usuários denominamos de design de software.

Design compreende as atividades de concepção, especificação e prototipação de um artefato.  O software como um produto - um artefato virtual - precisa ser concebido, especificado e prototipado. Precisamos trazer para o desenvolvimento de software a atividade de design que é realizada no desenvolvimento de qualquer produto industrial.

Design poderia ser traduzido tanto por projeto como por desenho. Entretanto, estes dois termos não expressam exatamente o que é design. Projeto é um termo mais abrangente do que design, pois se aplica a projeto de pesquisa, projeto de desenvolvimento de um produto e envolve planejamento, metodologia, cronograma, recursos, etc. Desenho é uma tradução utilizada no sentido de Desenho Industrial (industrial design), mas leva a conotação de que a atividade resume-se a elaborar os diagramas que descrevem os modelos do produto. Por estes motivos vamos utilizar o termo em inglês: design. Para quem faz o design, vamos usar os termos designer, projetista ou desenhista. Segundo David Liddle,

"o design de software é o ato de determinar a experiência do usuário com um pedaço de software. Não tem nada a ver sobre como o código opera internamente ou se ele é grande ou pequeno. A tarefa do designer é especificar de forma completa e não ambígua a experiência global do usuário". [David Liddle, Design of The Conceptual Model, em Winograd, T.]
O design de software compreende a concepção, especificação e prototipação da partes "externas" e "internas" do software. A parte externa compreende o modelo conceitual da aplicação e a interface de usuário. A parte interna compreende a arquitetura de componentes de software e os algoritmos e estruturas de dados que implementam estes componentes.

O design de software envolve as atividades de concepção, especificação e prototipação:

A concepção e especificação da arquitetura dos componentes de software determinará toda a estrutura interna do software: os objetos, funções e estruturas de dados. Eles são responsáveis pelo funcionamento do software. 

Este e o próximo capítulo abordam o design da parte "externa" do software: o modelo conceitual e a interface de usuário. O design da parte "interna", a arquitetura de componentes de software e os  algoritmos e estruturas de dados serão vistos no capítulo 6.

5.2 Modelo Conceitual da Aplicação

Vimos que o software deve ser visto como um artefato virtual que compreende as soluções que foram concebidas para resolver os problemas dos usuários, isto é, auxiliá-los na realização de suas tarefas no domínio. Este artefato virtual é uma entidade abstrata que existe na mente dos usuários quando eles estão interagindo com o usuário.

A esta entidade virtual que os usuários imaginam damos o nome de Modelo Conceitual da Aplicação que ele adquire. Este modelo conceitual determina, para o usuário, quais os conceitos (ou objetos do domínio) que estão representados no software, o que ele pode fazer com a aplicação - a funcionalidade - e como ele pode interagir com a aplicação - o modelo de interação.

A idéia de modelo conceitual da aplicação é denominado diferentemente por diversos autores. Ele é chamado de virtualidade, modelo conceitual do usuário, modelo de usabilidade, metáfora de interface e várias outras denominações.

Num editor de documentos como o MS Word, por exemplo, temos diversos conceitos que permitem ao usuário entender como está estruturado um documento e o que ele pode fazer com ele. No Word encontramos os conceitos de página, bordas de página, margens, parágrafos, recuos de parágrafos, espaçamento entre linhas, distância-da-primeira-linha, distância-antes-do-parágrafo, tamanho da letra, estilo da letra e diversos outros. Mais adiante apresentaremos um exemplo de um modelo conceitual para um editor de texto.

A elaboração de um modelo conceitual é fator determinante no sucesso de uma aplicação. O modelo conceitual precisa ser concebido e especificado adequadamente pelo designer, de acordo, com as necessidades, capacidade e limitações dos usuário. Para que o modelo seja adequado aos usuários, a especificação dos requisitos é fundamental. Nela encontramos, os papéis de usuários, o modelo de tarefas, os casos de uso, os conceitos do domínio e outras informações. A partir delas temos condições de elaborar um modelo conceitual que seja adequado aos requisitos dos usuários.

Para que a aplicação seja utilizada adequadamente é preciso que o usuário conheça o modelo conceitual da aplicação que foi elaborado pelo designer. Para isto é preciso que ele seja comunicado adequadamente ao usuário. Uma das formas de comunicar este modelo é através dos manuais de usuário ou de treinamento feito por pessoas especializadas. A outra forma é tentar expressar os conceitos através da interface de usuário. A interface é quem oferece a imagem externa do sistema e que deve ser interpretada de maneira correta pelo usuário. Ela deve comunicar para o usuário quais os objetos do domínio estão representados, o que ele pode fazer (a funcionalidade) com este conceitos e como ele pode interagir (o modelo de interação) com esta funcionalidade. No capítulo 5 veremos como o design da interface de usuário deve ser feito para expressar o modelo conceitual da aplicação.

5.2.1 Exemplo: o modelo conceitual de um sistema operacional

Ao utilizarmos um sistema operacional como o MS DOS sabemos que podemos construir, armazenar e organizar arquivos de software. Um arquivo é na verdade uma seqüência de bits como começo e fim definidos. Para o usuário o arquivo é algo conceitual (um conceito da aplicação) que se refere a documentos, programas, dados, etc. Esta entidade conceitual surge na mente do usuário por que ele tem um nome, um tipo, uma data de criação e uma tamanho em bytes. Arquivos são armazenados em discos em trilhas e setores e podem ser localizados a partir de uma tabela que associa o seu nome ao local físico. Para o usuário, arquivos são colocados "dentro" de uma outra entidade conceitual: o diretório.

Arquivos e diretórios são os conceitos da aplicação e podem ser criados, destruídos ou modificados por diversas funções da aplicação. Estas funções são, por exemplo, copiar arquivo, apagar arquivos, construir diretórios, remover diretórios, colocar arquivos em um diretório, mover arquivo de um diretório para outro, etc. Esta funções são também entidades virtuais representadas por uma nome que devem indicar, para o usuário, o que o sistema faz. Por exemplo, o sistema operacional não coloca arquivos dentro de um diretório. Isto só existe na mente do usuário. O que o sistema faz é trocar o endereço físico do arquivo na tabela de arquivos e diretórios. Entretanto, a visão de que diretórios são recipientes que armazenam arquivos é muito mais útil para o usuário. Ela permite ao usuário criar na sua mente conceitos da aplicação que permitem a ele entender o que fazer com o sistema e raciocinar melhor sobre ele.

O sucesso de uma aplicação vai depender justamente da criação deste modelo conceitual. Quanto mais claros forem o conceitos e as operações que se pode fazer com  eles, mais o usuário vai saber como aplicá-los na resolução de seus problemas. O sucesso de sistemas como o Macintosh ou o MSWindows (que copiou o primeiro) deve-se à construção de modelos conceituais mais familiares para o usuário. Os conceitos de pastas e objetos e a representação deles através de janelas e ícones permite ao usuário criar imagens mentais mais claras e que são familiares as atividades que eles realizam num escritório. O conceito de pasta como recipiente é mais claro que o de diretório (que na verdade é uma lista). No ambiente Windows o usuário move objetos (documentos, aplicativos, figuras, etc.) de uma pasta para outra e para o topo-de-mesa (desktop) como faria no seus escritório.

No MS DOS, o usuário adquire este modelo conceitual (as noções sobre diretórios e arquivos) ao ler o manual de usuário. No sistema Unix, da mesma forma, é o manual do usuário quem mostra para o usuário quais os conceitos da aplicação. Veja como exemplo um trecho do manual do Unix onde são apresentados os conceitos de arquivos e diretórios.

A interface de usuário é fundamental para que este modelo conceitual seja comunicado ao usuário. Ela é o melhor meio para que expressar os conceitos da aplicação e as funções que podem ser utilizadas. No MS DOS, a interface é muito pouco expressiva. Na interface o conceito de diretório é visualizado por ele como uma lista de nomes, tipos, tamanhos e datas, que representam cada arquivo do diretório. Cada arquivo é referenciado individualmente pelo seu nome. No Windows 95, o modelo conceitual é representado por desenhos gráficos que representam os conceitos da aplicação de maneira mais clara.

A interface de usuário também tem o papel de permitir ao usuário interagir com o sistema, comandando as funções da aplicação e visualizando o estado dos conceitos do domínio. No caso do MS DOS, a interface oferece comandos como copy, del, mkdir e vários outros para que o usuário possa interagir com os conceitos do domínio através das funções da aplicação.

A concepção do modelo conceitual como vimos é fundamental para o sucesso da aplicação. A criação de uma interface de usuário que expresse uma imagem deste modelo é também outro fator importantíssimo para que usuários compreendam melhor o que podem fazer com o sistema. No capítulo 5, veremos como realizar o design de interfaces que expressem melhor o modelo conceitual da aplicação

5.2.2 Um modelo conceitual básico para sistemas interativos

Qualquer artefato quando utilizado por alguém permite que ele elabore mentalmente um modelo conceitual do artefato. Mesmo que este modelo não tenha sido especificado explicitamente, o usuário, ao utilizá-lo, cria na sua mente os conceitos a respeito daquela aplicação. É tarefa do designer, ao fazer o design de um produto, determinar quais os conceitos que estão associados a ele. Alguns produtos têm conceitos que são comuns a maioria deles. Os conceitos de volume, brilho, cor e canal são comuns a televisores. Encher, lavar, enxaguar e centrifugar são conceitos que se referem a operações que podem ser feitas em máquinas de lavar. Entretanto, não existe um obrigação de que todos os produtos possuam os mesmos conceitos.

Nos sistemas computacionais interativos o modelo conceitual da aplicação é formado por alguns tipos de conceitos que são comuns a maioria deles. Evidentemente, cabe ao designer determinar quais os conceitos são úteis para a aplicação que ele está projetando. Vamos utilizar alguns tipos pré-definidos de conceitos. Eles são os objetos e as funções da aplicação e os comandos de função. Os conceitos do domínio como objetos, propriedades e relacionamentos devem ser representados no sistema para que os usuários possam operar sobre eles. Estas operações - as funções da aplicação - permitem que os conceitos sejam criados, transformados, destruídos, etc. Os comandos de funções permitem ao usuário controlar a execução de uma função pelo computador.

O conceito de objeto da aplicação refere-se às representações abstratas das diversas coisas que podemos distinguir num domínio e que são utilizadas pelos usuários para realizar as suas atividades. Num domínio de biblioteca são exemplos de objetos do domínio os livros, as revistas, o título do livro, os autores, o assunto, os números e volumes das revistas, o número de cadastro do livro, o nome do usuário, o número de cadastro do usuário e diversos outros. Num domínio de edição de textos estes conceitos podem ser documento, página, parágrafo, fonte, etc. Os objetos do domínio possui propriedades que os caracterizam e podem estar relacionados entre si.

Ao fazermos o design de um software devemos determinar quais os objetos do domínio que serão representados como objetos da aplicação e quais novos poderão ser criados. Um sistema de biblioteca deve poder representar os objetos do domínio biblioteca listados acima. O objeto livro pode ser representado pelos conceitos da aplicação informações-de-livro de título, autor, assunto e número de referência.

Atenção! Na especificação do modelo conceitual não estamos interessados ainda em como eles vão ser representados computacionalmente, isto é, qual estrutura de dados será utilizada para representar o conceito numa linguagem de programação. Isto só deverá ser feito no design da arquitetura e dos componentes do software. Também não vamos representar ainda como o conceito será visto pelos usuário - se na forma de um ícone, de uma tabela, de uma lista, etc. Por enquanto estamos interessado em fazer uma especificação abstrata dos conceitos.

As funções da aplicação são responsáveis por operações com os conceitos do domínio. Elas devem determinar quais transformações ocorrem no sistema e quais são os conceitos que são modificados, criados ou destruídos. A funções modificam o estado do sistema. Um determinada função da aplicação FA1 pode levar o sistema de um  estado E1 de para um estado E2. Os estado inicial que o sistema está antes que uma determinada função seja executado é também chamado de pré-condição. O estado final, isto é, após a função da aplicação ter sido executada é chamado de pós-condição.

Por exemplo, a função da aplicação armazenar nome-do-cliente na lista-de-nomes deve ter como pré-condição que o nome-do-cliente tenha sido fornecido e que a lista-de-nomes não possua o nome-do-cliente já armazenado. A pós-condição é que nome-do-cliente esteja armazenado na lista-de-nomes ao final da operação.

A execução de cada função da aplicação deve ser controlada por comandos de função. Este conceito refere-se ao conjunto de ações que o usuário deve desempenhar para que uma determinada função seja iniciada, interrompida ou cancelada, por exemplo. As ações que o usuário deve fazer são aquelas que ele desempenha com os dispositivos da interface de usuário, como pressionar tecla X, escrever um nome com o teclado, pressionar com o mouse, mover com o mouse, etc. Existem diferentes formas de interação que determinam comandos de função de diversas natureza. No MS DOS, os comandos são elaborados pela digitação de sentenças. Este estilo é chamado de linguagem de comando. No Windows 95/98, os comandos são desempenhados pelo acionamento de objetos da interface num estilo chamado de manipulação direta.

Veremos, a seguir, como especificar os conceitos do domínio. Mais adiante veremos a especificação de funções da aplicação e na seção 5.3 veremos a especificação do modelo de interação que inclui os comandos de função.

5.2.3 Especificando o modelo conceitual da aplicação utilizando a UML

Modelos conceituais podem representar qualquer sistema na natureza. No sistema solar temos os conceitos de planetas, órbita, força gravitacional e outros. A física utiliza de notações matemáticas para representar os conceitos que descrevem o sistema solar. A língua portuguesa também pode ser utilizada para descrever conceitos de um domínio. Na biologia, os conceitos referentes a espécies, gênero, família, classes, ordem, filo e reino dos seres vivos são descritos em português e latim.

Não existem muitas técnicas ou notações específicas para o design do modelo conceitual de sistemas interativos. Neste modelo o que estamos querendo representar são os conceitos que se formam na mente do usuário ao utilizar o sistema. Algumas das técnicas e notações de inteligência artificial como redes semânticas, frames e scripts podem ser utilizadas. Seria interessante que a linguagem utilizada permitisse-nos construir um modelo que pudesse ser "traduzido" tanto em elementos da interface como em componentes de programação.

Utilizaremos a notação UML (Linguagem de Modelagem Unificada) como forma de representar conceitos de objetos e relações da aplicação. Com os diagramas de classes também podemos mostrar como os objetos estão associados com as funções da aplicação - que haviam sido representadas de maneira simplificada como casos de uso na UML.

Classes

Tradicionalmente, representamos um objeto dando-lhe um nome e descrevendo as propriedades ou atributos que os distinguem de outros objetos. As classes em UML permitem representar conceitos descrevendo o seu nome, seus atributos e relacionamentos. A classe descreve o conceito abstraindo os valores de propriedades específicos, permitindo a referência genérica a objetos do domínio. A noção de classes como o agrupamento de objetos está presente em nossa linguagem e em diversas ciências. O processo de classificação é estudado desde a filosofia da Grécia antiga.

Em computação existem diversas metodologias para análise e design orientado-a-objetos que permitem a representação de classes. Elas são bastante parecidas entre si. A UML apresenta sua própria notação para a representação de classes através de diagramas de classes. Estas notações tem por objetivo a modelagem de programas orientados-a-objeto. Entretanto, na atividade de design utilizaremos diagramas de classes como propósito de modelar objetos da aplicação da forma como são vistos pelo usuário e não da forma como são implementados.

Uma classe é uma descrição de abstrata de objetos que possuem atributos comuns ou estão relacionadas a outros objetos. Cada classe possui um nome que a distingue de outras classes. Este nome é qualquer seqüência de letras, de preferência um termo do vocabulário do domínio.

Um atributo é o nome dado a uma propriedade do conceito representado pela classe. Cada objeto que pertence a uma determinada classe possui valores específicos para os atributos que são comuns a uma determinada classe. Por exemplo, a classe cliente possui os atributos nome, endereço, telefone e data-de-nascimento. Um certo cliente (um objeto do domínio) é representado pelos valores específicos dos atributos que descrevem as propriedades.  Os clientes João da Silva, R. Salgado Filho, 2126666, 12/2/55 João da Silva, R. Hermes da Fonseca, 2122121, 29/2/65 são distintos, pois possuem valores específicos para os atributos que caracterizam a classe cliente. Nos diagramas de classes os atributos (o nome da propriedade) são identificados por um nome enquanto que os seus valores podem ser representados por números, nomes, caracteres especiais e outros símbolos que forem apropriados.

Um conceito pode ser representado por uma classe simples, isto é, que não possui algum atributo específico. A identificação numérica única de um aluno é um conceito que pode ser representado simplesmente pela classe matrícula-do-aluno sem nenhum atributo. Este conceito pode, eventualmente, ser um atributo de uma outra classe (a classe que representa o conceito aluno, por exemplo). Entretanto, podemos representar também a identificação por uma classe cujos atributos sejam ano de ingresso, semestre, número do centro, número do curso, número pessoal e os valores sejam, respectivamente 92-1-8-62-2321.

Atenção! Os diagramas de classes da linguagem UML são mais genéricos do que precisamos para representar classes e objetos da aplicação. Eles foram projetados para permitir também a modelagem de classes de uma linguagem orientada a objetos como C++, Smalltalk ou Java. Por enquanto utilizaremos este diagrama apenas para representar objetos da aplicação. Utilizaremos diagramas de classes para representar classes de linguagens de programação mais adiante quando estivermos modelando a arquitetura de componentes de software.

Objetos

Objetos são instâncias de classes. Objetos possuem existência num domínio.  No exemplo visto anteriormente, João da Silva, R. Salgado Filho, 2126666, 12/2/55 é um objeto da classe cliente. Os valores de atributos representam a existência de um cliente específico. João da Silva, R. Hermes da Fonseca, 2122121, 29/2/65 é um outro objeto e é representado pelos valores de suas propriedades diferenciais.

Na UML um objeto é representado por retângulo, com o nome do objeto seguido por um ":"(dois pontos) e o nome da classe ao qual ele pertence.

Relacionamento

Uma classe pode estar relacionada com outras classes. Isto significa que os objetos representados pela classe estão relacionados de alguma forma com os objetos da outra classe. Uma relação genérica é representada por uma associação. Cada associação é identificada por um nome. As classes que estão ligadas a uma associação assumem papéis específicos. Por exemplo, a relação entre os conceitos pessoa e empresa pode ser representada pela associação trabalha-em. Nesta associação a pessoa assume o papel de empregado e a empresa o papel de empregador. Numa associação é preciso especificar a multiplicidade. Por exemplo, uma pessoa pode trabalhar-em uma única empresa (1) e uma empresa pode empregar uma ou mais pessoas (1 . . *).

Um importante tipo de relacionamento entre conceitos, bastante comum na maioria dos modelos, é a generalização. A generalização relaciona um conceito mais genérico a um conceito que seja mais específico. O primeiro é chamado de superclasse enquanto o conceito mais específico é a subclasse. A generalização é também conhecida como é-um-tipo-de. Por exemplo, um retângulo é-um-tipo-de figura. A figura é a superclasse e o retângulo a subclasse. Círculo e polígono são conceitos que também são subclasses do conceito figura. Quadrado é uma subclasse de retângulo e, conseqüentemente, também é subclasse de figura. A relação especialização é oposta a generalização. Ela indica que uma subclasse é uma especialização da superclasse. Quadrado é uma especialização de figura.

Um outro relacionamento bastante comum é a agregação, também conhecida como parte/todo. Esta relação ocorre entre conceitos que são parte de um outro (o todo) e pode ser representado pela associação é-parte-de ou pela sua relação inversa tem. Por exemplo, a roda é-parte-de carro ou, usando a associação inversa, carro tem roda. Nesta associação os papéis desempenhados pelas classes relacionados são, justamente, parte e todo. A multiplicidade também pode ser representada na associação de agregação. Uma empresa tem (0 . . *) departamentos, isto é uma empresa pode ter nenhum ou vários departamentos. Um departamento é-parte-de (1) empresa, significa que o departamento pertence a uma única empresa.

5.2.4 Especificando Funções da Aplicação usando Diagramas  de Atividades

Os diagramas de casos de uso descrevem quais as funções da aplicação são de interesse de cada papel de usuário. Veremos agora como os diagramas de atividades permitem descrever o comportamento de cada função da aplicação. mais adiante mostraremos como os diagramas de classes permitem representar como as funções da aplicação estão relacionadas com os objetos da aplicação. 

O diagrama de atividades é mais um diagrama da UML. Ele permite modelar aspectos dinâmicos de um sistema. Em particular, ele é um gráfico de fluxo (flowchart) que permite mostrar o fluxo de controle de atividade para atividade descrevendo a seqüência de passos no processo computacional.

Graficamente, um diagrama de atividades é um grafo composto por nós e vértices. Eles são utilizados para:

Por enquanto, vamos utilizar os diagramas para modelar apenas as funções da aplicação.
Normalmente, um diagrama de atividades é composto por: Um diagrama de atividades visa mostrar com as coisas acontecem no sistema. Um estado de ação representa uma situação na qual o sistema encontra-se quando está realizando computações. Cada estado de ação é representado por uma figura específica com uma descrição da computação realizada. Esta descrição é o predicado de uma sentença do tipo calcule valor, imprima documento, etc.

Estados de ação são atômicos, isto é, eles não podem ser decompostos. Isto significa que quando a ação esta sendo executada ela não pode ser interrompida. Considera-se que o tempo de execução da ação é insignificante.

Já os estados de atividades podem ser decompostos e, eventualmente, representados em diagramas de atividades independentes se for necessário (normalmente por questões de clareza). Os estados de atividades não são atômicos e podem ser interrompidos durante a ocorrência de eventos. O sistema permanece num estado de atividade durante um certo intervalo de tempo.

Um estado de atividade é composto por outros estados de atividades ou de ações. O estado de ações é, portanto, um estado de atividade atômico que não pode ser mais decomposto. O diagrama de atividades descreve o fluxo de controle do sistema nos diversos estados de atividade e ações.

A figura para representar o estado de atividade é a mesma do estado de ação, exceto que o primeiro pode ter partes adicionais tal como ações de entrada e saída (ações que estão envolvidas quando se entra ou sai do estado) e especificação de sub-máquinas.

Quando a ação ou atividade de um estado termina o fluxo de controle passa imediatamente para o próximo estado de ação ou de atividade. Este fluxo é especificado através de transições que mostram o caminho de uma ação ou atividade para o próximo estado de ação ou de atividade. Na UML, a transição é representada por uma linha com uma seta indicando a direção do fluxo.

Num diagrama de atividade existe uma transição que identifica a passagem do estado inicial para um estado de ação ou de atividade e uma outra que identifica a passagem para o estado final. O estado inicial é identificado por uma bola pequenina de cor preta e o estado final é representado por um círculo um pouco maior com a bola preta no seu interior.

A transição seqüencial entre os estados nem sempre ocorre por um caminho único. Caminhos alternativos são representados por uma decisão (branching). Na UML a bifurcação é representada por um losângulo conectando linhas que representam as transições. No diagrama uma expressão lógica pode ser acrescentada para indicar em quais condições cada caminho pode ser seguido.

Dois estados de ação ou atividades podem ocorrer simultaneamente. Para indicar a simultaneidade ou concorrência a UML oferece as estruturas bifurcação e junção. Eles são representados por uma barra de sincronização que indicam quando uma transição se divide em duas ou mais ou quando duas ou mais juntam-se em uma. Uma bifurcação possui uma transição chegando e duas ou mais saindo. A junção, por sua vez, possui duas ou mais transições chegando e uma saindo para um outro estado de ação ou atividade.

Conceitualmente a bifurcação e a junção permitem representar dois estados de atividades ou ações simultâneos, isto é, sendo executando ao mesmo tempo. Na implementação esta concorrência pode ser real ou uma simulação com processos intercalados.

Raias são utilizadas para agrupar estados de atividades ou de ações de maneira a representar de quem é a responsabilidade por aquela ação.Cada raia representa um locus de atividade e é identificada por um nome.

Para modelar uma função da aplicação (ou uma operação) usando diagrama de estados você deve:

O diagrama de atividades é um tipo de máquina de estados. Ele tem por objetivo descrever os estados de atividades e o fluxo de controle, isto é, os caminhos para passar por cada um dos estados. A máquina de estados tem por objetivo descrever como o sistema (ou uma função em particular) muda de estados na ocorrência de eventos externos a ele. No diagrama de atividades descreve-se como o sistema muda de um estado de atividade para outro quando termina a atividade que está sendo realizada, independente da ocorrência de um evento externo.

5.2.5 Especificando funções da aplicação usando Diagrama de Estados

Uma máquina de estados permite modelar os aspectos dinâmicos de um sistema. Ela mostra o comportamento do sistema em termos de estados pelos quais ele passa ao longo de sua existência. A máquina de estados mostra com o sistema reage a eventos externos. Além disso, ela mostra a ordem na qual o sistema assume determinados estados.

Máquinas de estados podem ser utilizadas para modelar o comportamento de componentes individuais de software, funções de aplicação (ou casos de uso, como são chamadas na UML) ou um sistema inteiro.

A máquina de estados é uma abstração bastante utilizada em computação. A teoria da computação nos mostra como descrever matematicamente uma máquina de estados. Também podem ser encontradas notações com o mesmo potencial em diversas metodologia de desenvolvimento de software.

A UML proporciona uma representação gráfica para máquinas de estados: o diagrama de estados. Esta notação permite representar estados, transições, eventos e ações utilizando símbolos específicos, como mostra a figura.

Uma desvantagem do diagrama de estado é ter de definir todos os possíveis estados de um sistema. Isto não é problema quando se está modelando uma única função, mas quando se descreve o sistema completo quando o sistema assume dezenas ou até centenas de possíveis estado o diagrama pode se tornar inviável. Neste cursos vamos usar máquinas de estados para representar o comportamento de cada função da aplicação ou caso de uso.

Um estado é uma condição ou situação na qual um objeto do sistema (ou o próprio sistema) está durante o seu tempo de "vida". O sistema pode permanecer num estado até que ocorra um evento externo, até que uma determinada atividade que ele esteja executando termine ou que alguma condição seja satisfeita. O sistema normalmente passa por diversos estados. Graficamente um estado é representado por um retângulo com as bordas arredondadas.

Um estado tem várias partes:

Cada máquina de estado tem um estado inicial que indica o estado no qual o sistema encontra-se quando a função é iniciada. Quando se está modelando funções, este estado inicial é também chamado de pré-condição. Uma máquina de estado pode ter um ou mais estados finais que indica as situações, também chamada de pós-condições, na qual o sistema deve estar para considerarmos que a função foi executada como esperado.

Um evento é a especificação de uma ocorrência significante no espaço e no tempo. No contexto de máquina de estados o evento é uma ocorrência que leva a uma transição. A ocorrência pode ser externa ao sistema, interna (outra parte do sistema) ou um instante de tempo atingido.

Uma  transição é um relacionamento entre dois estados indicando que o sistema quando está num determinado estado irá para um outro estado na ocorrência de um certo evento e realizará uma certa ação. A transição representa a mudança de estado.

Uma transição tem cinco partes (algumas em comum com os estados):

Uma  ação ou atividade é uma execução realizada pelo sistema. A ação é uma computação atômica, indivisível, enquanto a atividade pode ser sub-dividida em outras atividades ou ações.

5.2.6 Exemplo: especificando uma função da aplicação

No capítulo 4, apresentamos a especificação informal de um caso de uso validar cliente. Vejamos agora como a função da aplicação que implementa este caso pode ser especificada usando diagrama de atividades e de estados.

As figuras abaixo mostram os diagramas de estados que descrevem o comportamento do sistema em decorrência dos eventos do usuário. Na primeira figura estão descritos os estados de ler e de verificar a senha. Na figura imediatamente abaixo apresentamos os sub-estados do estado lendo senha do diagrama de cima. É importante ressaltar que estes não são os únicos diagramas possíveis.

A próxima figura mostra o diagrama de atividades para a função validar cliente.

A seguir, mostraremos um diagrama alternativo para a função validar cliente cujas atividades ler senha e pesquisar senha usuário são realizadas em paralelo.

Estes diagramas podem ser modificados. Você pode fazer o seu próprio design e modelar do jeito que você quiser. Como exercício, experimente modelar o fato de que cada cliente poder apenas fazer três tentativas.

5.2.7 Associando Funções da Aplicação a Objetos do Domínio usando Diagramas de Classes.

Vimos que uma Função da Aplicação opera sobre objetos, modificando seu estado ou comportamento. As classes e os relacionamentos permitem elaboramos um modelo dos objetos do domínio com um potencial equivalente aos Diagramas Entidade-Relacionamento utilizados nas metodologias estruturadas e no projeto de banco de dados. Os diagramas de classes, entretanto, permitem representarmos também as operações ou funções que são associadas a uma classe.  Com isto podemos descrever quais as funções da aplicação que podem ser realizadas com os objetos representados por uma classe.

Na modelagem conceitual pretendemos representar como as funções da aplicação (os casos de uso) estão associados com alguns dos objetos da aplicação representados como classes. Por exemplo, num editor de texto podemos modelar as páginas de um documento através da classe página, cujos atributos são tamanho e margem direita, esquerda, superior e inferior. Para que o usuário possam modificar as propriedades da página do documento o editor de texto deve oferecer as funções definir tamanho e definir distância das margens.

Usando o diagrama de classes podemos representar a classe página, da seguinte forma:

É importante ressaltar que no modelo conceitual nosso objetivo é definir quais funções o sistema oferece para o usuário modificar o objeto representado pela classe. A função definir tamanho permite ao usuário modificar tamanho da página. Da mesma forma definir distância das margens modifica a distância entre a borda e a área onde o texto vai ser escrito. Na modelagem conceitual devemos representar numa classe apenas as funções da aplicação que podem ser controladas pelo usuário e que modificam os objetos da classe à qual ela está relacionada.

5.3 O Modelo de Interação Usuário-Sistema

Vimos que o modelo conceitual da aplicação deve especificar de maneira abstrata o modelo de interação e de funcionalidade do sistema. Na seção 5.2 mostramos como especificar o modelo conceitual de uma aplicação em termos de conceitos do domínio e funções de aplicação. Este modelo deve ser derivado da especificação de requisitos como forma de garantir que a aplicação satisfaz as necessidades dos usuários. Os casos de uso são um ponto chave neste processo. Eles associam as tarefas que os usuários querem realizar para atingir as suas metas às funções da aplicação que são oferecidas pelo software. Estas funções da aplicação operam sobre conceitos do domínio. A especificação das funções e dos objetos da aplicação determinam a funcionalidade do software. Vimos como ela pode ser especificada através da UML (Linguagem de Modelagem Unificada) que permite descrever o comportamento de cada caso de uso através de diagramas de estados e de atividades, bem como outros diagramas que não foram estudados.

Entretanto, a especificação da funcionalidade do software que determina o que se pode fazer com o sistema ainda não é suficiente. É preciso ainda especificar como o usuário vai interagir com o sistema. Esta especificação também deve ser feita de maneira conceitual e abstrata da mesma forma que na funcionalidade. Neste caso, estamos especificando a forma como o usuário interage com o sistema independente de uma interface de usuário específica.

Nesta seção vamos mostrar como especificar o modelo de interação da aplicação. Para cada caso de uso vamos descrever o processo de interação entre o usuário e o sistema.

5.3.1 O processo de interação usuário-sistema

Vimos que as metas do usuário são satisfeitas pela execução de tarefas pelo usuário que façam o sistema executar cada função da aplicação. O modelo de tarefas, visto no capítulo 3, mostram os planos do usuário para atingir cada uma das suas metas. Na especificação dos requisitos os modelos de tarefas descrevem as hierarquias de sub-metas até o caso de uso -- a função da aplicação que o sistema deve oferecer. Ao detalharmos mais ainda este plano, descreveremos as ações (ou operações, como são chamadas no GOMS) que o usuário deve realizar com o sistema. Este conjunto de ações é denominado de comando de função.

A figura abaixo ilustra a associação entre os casos de uso, o modelo de tarefa e os diagramas utilizados para descrever o comportamento de cada função da aplicação. Ela também situa o que estamos falando em todo o contexto do desenvolvimento de software que temos abordado desde a etapa de análise e especificação de requisitos. Vimos que precisamos analisar as metas dos usuários e elaborar o modelo de tarefas para decidir quais casos de uso o sistema deve oferecer para o usuário. Cada  caso de uso determina uma função da aplicação. O conjunto de funções da aplicação definem a funcionalidade do sistema e podem ser especificados em diagramas de classes, de estados, de atividades e outros diagramas. Mais adiante veremos como modelar a interação a através de diagramas de seqüências.

O modelo de interação é composto pelo conjunto de comandos de funções necessários para o controle de cada função da aplicação determinada pelos casos de uso. Ele deve também determinar quais as ações que o sistema deve fazer apresentar as informação ou resultados ao usuário associados com cada função da aplicação.  

Por exemplo, se a meta do usuário de um editor de texto for Formatar documento, vimos no capítulo 3 que o modelo de tarefas especifica sub-metas como formatar página, formatar parágrafo e formatar fonte, que por sua vez podem ser decompostas, cada uma, em outras sub-metas. A sub-meta definir tamanho da página pode ser atingida diretamente pela função da aplicação de mesmo nome, caracterizando um caso de uso. Até então não dissemos o que o usuário tem que fazer para mandar o sistema executar esta função.

O usuário, neste caso, tem que fornecer o valor do tamanho da página e mandar o sistema modificar o tamanho atual para o tamanho desejado. Ele pode fazer isto, por exemplo, digitando o valor do tamanho da página desejado numa caixa de texto e acionando um botão de modificar tamanho. O comando de função seria formado por estas duas ações básicas.  Ele também poderia elaborar um comando do tipo "modifique tamanho para A4".

O comando de função deve determinar quais as ações que o usuário deve fazer para que uma função da aplicação seja executada pelo sistema.  Podemos identificar alguns tipos de ações básicas que o usuário costuma realizar ao interagir com o sistema. Elas são chamadas de interações básicas e podem ser:

Na especificação conceitual do modelo de interação o designer pode limitar-se a uma descrição informal, como mostrado acima. 

É importante ressaltar que estamos chamando de comando as interações necessárias para um único comando. Existe uma associação direta de um comando para cada função da aplicação. O comando requer um conjunto de interações para que uma certa função seja controlada. Ele pode ter diversos efeitos sobre a função como veremos mais adiante. Se para uma determinada meta que o usuário tenha ele necessite de várias funções da aplicação, ele precisará realizar as interações de cada comando de função.

As diversas interações que o usuário tem de realizar normalmente são composições de interações básicas. Ele pode realizar, por exemplo, uma seqüência de acionamentos para comandar uma determinada função. Em outra situação o comando de função poderia ser composto pela repetição de uma digitação de valor mais o acionamento de um widget. Podemos identificar alguns tipos de estruturas de interações. São elas:

A seqüência é uma das estruturas mais utilizadas. Ela determina que o usuário deve seguir uma seqüência específica de interações. Por exemplo, se para acionar a função definir tamanho da página o usuário precisa informar primeiro o tamanho e depois mandar iniciar a execução o designer pode especificar que o comando tem uma estrutura sequencial composta pelas interações digitar tamanho e acionar botão iniciar.

A seleção pode ser utilizada quando o designer quer dar ao usuário a opção de escolher alguma interação. Para a função do exemplo anterior o usuário poderia ter a opção de escolher entre acionar o botão iniciar e acionar o botão cancelar no comando de função.

A repetição deve ser utilizada quando o comando requer que uma interação ou uma estrutura de interações seja repetida para que a função seja executada. O exemplo mais comum é a repetição do clique com o mouse (duplo clique). Um outro exemplo de repetição seria um  comando para a função definir margens no qual o usuário tivesses que repetir a interação digitar distância para cada uma das quatro margens da página.

O agrupamento ocorre quando o usuário tem a sua disposição diversas interações e ele pode realizá-las sem preocupar com a ordem. Por exemplo, para um comando para a função imprimir o usuário pode fazer as interações digitar número de cópias e digitar o nome do documento, em qualquer ordem.

A combinação determina, por exemplo, que o usuário deve ter que realizar as interações pressionar tecla SHIFT e mover o mouse para comandar uma função.

Atenção! A grande maioria das aplicações existentes foram concebidas e especificadas sem estas noções em mente. Estamos aqui fazendo uma proposta de como as coisas poderiam ser para que o modelo conceitual da aplicação fosse melhor estruturado e mais lógico, possibilitando que os sistemas pudessem ser mais facilmente utilizados e aprendidos.

5.3.2 A interação com funções da aplicação

O nosso modelo de interação é descrito em função dos casos de uso. Para cada caso de uso temos associada a ele uma função da aplicação que deve ser implementada pelo software. A função da aplicação é uma entidade conceitual que pode ser implementada por um ou mais componentes de software -- funções, procedimentos, métodos de objetos ou qualquer forma de implementação computacional. A função da aplicação é algo que o sistema oferece para que o usuário realize uma determinada tarefa para atingir as suas metas.

A função da aplicação deve estar sob o controle do usuário. É ele quem deve tomar a iniciativa de quando a execução da função deve ser iniciada, interrompida, cancelada, terminada e outras opções de controle operacional. O designer deve determinar a maneira como o usuário pode controlar cada função e quais as opções de controle serão fornecidas. São exemplos de controle operacional iniciar, interromper, continuar, concluir, cancelar, desistir e outros.

O designer pode especificar outros controles que sejam convenientes para a função da aplicação que ele esteja projetando. Ele deve ainda determinar como cada uma destas opções ele deve ser controlada pelo usuário, isto é, qual ação o usuário deve fazer.

Por exemplo, na função da aplicação sacar dinheiro o usuário pode ter as opções de iniciar ou desistir, antes de iniciar e cancelar após ele ter mandado iniciar. Estas opções podem ser acionadas através de teclas ou de botões.

Além do controle operacional, o usuário deve fornecer as informações necessárias para a execução da função. Estas informações são os operandos da função da aplicação. Existem diversas formas do usuário fornecer informações (os operandos) para cada função da aplicação. O designer deve verificar quais operandos são necessários e de que maneira o usuário irá fornecer cada informação.

São exemplos de operandos senha do cliente e o número da conta e o valor de saque na função sacar dinheiro. Os valores de vendas e compra necessários para o cálculo de lucro são também exemplos de operandos.

Cada função da aplicação pode estar em um ou mais estados como vimos na seção anterior. O designer pode optar por mostrar ao usuário cada estado no qual a função está. O resultado final produzido por cada função também deve ser mostrado ao usuário.

5.3.3 Exemplo de especificação de modelos de interação

Utilizando os conceitos introduzidos acima, vamos fazer a especificação de comandos  para três funções da aplicação. Esta especificação será feita de maneira informação utilizando os conceitos de comando de função e interação, estruturas de interação. Cada uma das especificações é apenas uma possibilidade dentre várias possíveis. Ela reflete a decisão do projetista.

a. Comando para a função da aplicação consultar livro para um sistema de biblioteca.

Para o usuário consultar um livro ele deve primeiro fornecer informações sobre o autor, o título e o código ISBN. Estas informações são os conceitos do domínio necessários para que a busca seja realizada. Eles são os operandos da função.
Após fornecer os valores dos operandos, o usuário pode escolher entre comandar o início da busca, desistir de fazer a consulta, ou interromper a busca na base de dados.

Utilizando as estruturas vistas acima e algumas da interações básicas, podemos descrever este comando informalmente como:

Na seção 5.3, veremos como este modelo de interação pode ser traduzido em diferentes interfaces.

b. Comando para a função imprimir arquivos para um gerenciador de arquivos.

Para comandar a função que imprime arquivos (num suposto gerenciador de arquivo) o usuário deve fornecer os operandos da função para em seguida selecionar o controle de execução da função. Isto deve ser feito em seqüência. O projetista inicialmente optou por enviar uma mensagem direta para o usuário indicando o que ele fazer (Veja). A seqüência e a mensagem são estruturados num agrupamento, pois não importa a ordem que o usuário faça isto.

O comando requer que o usuário forneça o nome do arquivo a ser impresso, o nome da impressora e o número de cópias. O usuário deve poder escolher dentre as impressoras disponíveis e também configurá-la. O designer decidiu que o usuário apenas pode realizar os comandos de controle após ter fornecidos os dados. Neste caso os grupos de interações para fornecimentos dos dados e controle operacional devem estar estruturados com uma seqüência.  O fornecimento dos dados pode ser realizado em qualquer ordem (agrupamento). Para fornecer o nome do arquivo o usuário pode escolher entre digitar o nome diretamente ou selecionar de uma lista de nomes de arquivos (seleção). Para configurar uma impressora é necessário escolhê-la para ativar a mensagem de comando configurar impressora. Esta dependência entre as duas ações do usuário requer a utilização da estrutura combinação. O número de cópias deve ser fornecido diretamente.

Após ter fornecido os dados, o usuário pode escolher o controle operacional da função desejado. A função imprimir permite os controles iniciar, parar, interromper, continuar e desistir. O usuário deve selecionar (seleção) cada controle e acionar a opção correspondente.
 

Também na seção 5.3 apresentaremos uma interface que satisfaça esta especificação.

5.3.4 Especificando o modelo de interação com diagrama de interação UML simplificado

O diagrama de interação é mais um dos diagramas da UML (Linguagem de Modelagem Unificada) que utilizaremos. Para a especificação do modelo de interação usuário-sistema utilizaremos uma versão simplificada que poderá ser extendida mais adiante quando quisermos expressar a interação entre os componentes (internos) do software. Na versão simplificada, modelaremos apenas a interação (externa) entre usuário e as funções da aplicação.

Além disto, utilizaremos apenas o diagrama de seqüência de interação que é uma das duas formas de diagramas de interação. O outro, o diagrama de colaboração, é desnecessário para a interação usuário-sistema uma vez que eles são apenas os dois únicos agentes colaboradores.

O diagrama de seqüência de interação tem por objetivo descrever, como o próprio nome indica, a seqüência de interações entre o usuário e o sistema ao longo do tempo. Podemos utilizar o diagrama para descrever a seqüência de interações básicas que compõem um comando de função, bem como para modelar toda a interação com as diversas funções da aplicação.

Uma limitação do diagrama de seqüência é não permtir descrever a estrutura de interações que vimos na seção 5.3.1. Também não é possível diferenciar as formas de mensagens que o sistema envia para o usuário. É possível fazer adaptações no diagrama para especificar as estruturas.

O diagrama representa o "tempo de vida" de cada uma dos agentes por uma linha de tempo vertical. A interação entre os dois agentes (usuário e sistema) é representada por setas na direção da informação que é enviada.

Por exemplo, o comando de função para definir tamanho, composto pela seqüência de interações básica digitar tamanho e acionar (botão) OK. No diagrama estas duas interações são representadas por setas na direção do usuário para o sistema. No diagrama estamos representando por uma barra vertical o "tempo de vida" do sistema. 


Anterior | Índice | Próximo
(C) Jair C Leite, 2000                                                          Última atualização: 12/04/01