Você está na página 1de 10

Nome: Carlos Eduardo de Santana

Turno: Manhã
Resumo dos 5 primeiros capítulos do livro Princípios de Análise e Projetos de Sistemas com UML -
Eduardo Bezerra. 3 edição

Capítulo 1:
Atualmente, a informação é um bem econômico, e para gerenciar essas informações criou-se os
sistemas de informações. O objetivo principal da construção de um sistema de informações é a
adição de valor à empresa ou organização na qual esse sistema será utilizado. O desenvolvimento de
um sistema de informações é uma tarefa complexa e um de seus componentes é o sistema de
software. Este componente envolve os módulos funcionais computadorizados que interagem entre si
para proporcionar ao(s) usuário(s) do sistema a automatização de diversas tarefas, aumentando a
produtividade na empresa ou organização.
A medida que o sistema de software cresce, a complexidade de seu desenvolvimento também
cresce. Para construir esses sistemas, é necessário um planejamento inicial. Assim, utilizam-se
modelos para projetar o sistema. Um modelo pode ser visto como uma representação idealizada de
um sistema a ser construído. Razões para se utilizar modelos na construção de sistemas:
1. Gerenciamento da complexidade: São consideradas apenas características relevantes à resolução
do problema, ou seja, modelos revelam as características essenciais de um sistema, baseando-se no
Princípio da Abstração.
2. Comunicação entre as pessoas envolvidas: No desenvolvimento de sistema, tem muitas
atividades a serem executadas e essas atividades se traduzem em informações sobre o sistema.
Assim, os modelos servem também para dividir as informações entre os indivíduos envolvidos na
construção do sistema.
3. Redução dos custos no desenvolvimento: Encontrar erros no modelo e consertar é muito menos
custoso do que refazer o sistema novamente.
4. Previsão do comportamento futuro do sistema: Com o comportamento previsto, podem ser
experimentadas diferentes soluções para um problema na construção do sistema.
Um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem um
significado predefinido. Modelos de sistemas de software também são compostos de informações
textuais com o objetivo de explicar ou definir certas partes desse diagrama. A junção do diagrama
com a informação textual, formam a documentação de um modelo.
Indispensável no desenvolvimento atual de sistemas de software é o paradigma da orientação a
objetos. Nesse contexto, um paradigma é uma forma de abordar um problema.
Alan Kay, um dos pais do paradigma da orientação a objetos, pensou em como construir um
sistema de software a partir de agentes autônomos que interagem entre si. Dessa forma ele
estabeleceu os seguintes princípios da orientação a objetos:
1. Qualquer coisa é objeto.
2. Objetos realizam tarefas por meio da requisição de serviços a outros objetos.
3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares.
4. Classes são organizadas em hierarquias.
No paradigma da orientação a objetos, são utilizados objetos interconectados. Cada objeto é
responsável por realizar tarefas específicas. É pela interação entre objetos que uma tarefa
computacional é realizada.
Na terminologia de orientação a objetos, coisas do mundo real são chamadas de objetos. E cada
ideia é chamada de classe de objetos. Uma classe é a descrição dos atributos e serviços comuns a
um grupo de objetos. É importante notar que uma classe é uma abstração das características de um
grupo de coisas no mundo real. Para fins de modelagem de um sistema somente um subconjunto de
características pode ser relevante.
Operação é o nome de alguma ação que o objeto pode fazer. Para realizar essas operações, ele
precisa receber uma mensagem requisitando tal operação. O estado de um objeto é o conjunto de
valores de seus atributos em um dado momento, e o recebimento de uma mensagem tem o potencial
de mudar o estado desse objeto. Objetos interagem através de mensagens com o objetivo de realizar
alguma tarefa dentro do sistema que estão inseridos.
Abstração é o processo de extrair as características mais importantes de alguma coisa e ignorar os
menos importantes. Isso nos permite gerenciar a complexidade de um objeto.
Objetos possuem comportamentos. O comportamento de um objeto são as operações realizadas
por ele. O encapsulamento é uma forma de limitar o acesso ao comportamento de um objeto. Se um
objeto precisar da ajuda de outro objeto, ele enviará uma mensagem requisitando tal operação, mas
não saberá o método que o outro objeto utiliza para realizar a operação. Por meio da interface de um
objeto, outros objetos sabem quais operações tal objeto pode realizar.
O encapsulamento é importante porque a implementação de uma operação pode ser trocada sem
que o objeto requisitante da mesma precise ser alterado. Dessa forma, há menos possibilidades de
fazer alterações no restante do sistema. No desenvolvimento de softwares modernos, é fundamental
manter as partes de um sistema o mais independente possível.
O polimorfismo é a capacidade de duas ou mais classes de objetos responderem à mesma
mensagem, cada um de sua forma. Dessa maneira, uma região de código cliente torna-se mais
simples pelo fato de não precisar conhecer as particularidades de um serviço, outros códigos farão o
serviço solicitado, cada um da forma que foram designados a fazer.
A generalização é a abstração de características e comportamento comuns de um conjunto de
objetos em uma classe. Sendo assim, uma classe descreve as características de um grupo de objetos
parecidos. Na generalização, classes semelhantes são agrupadas em uma hierarquia. Cada classe em
um nível de hierarquia herda as características e o comportamento das classes que estão associadas
acima dela.
Objetos podem ser compostos de outros objetos; esse é o princípio da composição. A composição
possibilita que criemos objetos a partir da reunião de outros objetos.
A lei de Moore estabelece que “a densidade de um transistor dobra em um período entre 18 e 24
meses”. Isso quer dizer que a capacidade de processamento de um processador duplica a cada 2
anos. Com isso, as formas de desenvolver um sistema evoluíram rapidamente até os dias atuais. As
técnicas de modelagem de sistemas orientados a objetos também evoluíram. Como existiam muitas
técnicas na década de 90, resolveram criar uma notação de modelagem padrão para a modelagem de
sistemas orientados a objetos. Daí surgiu a UML (Unified Modeling Language) como unificação
das notações, diagramas e formas de representação existentes na época.
A UML é uma linguagem visual para modelar sistemas orientados a objetos. Cada elemento
gráfico da UML possui uma sintaxe e uma semântica. A sintaxe de um elemento refere-se à forma
predeterminada de desenhar o elemento. A semântica define o que significa o elemento e com que
objetivo ele deve ser utilizado.
A UML é independente tanto de linguagens de programação quanto de processos de
desenvolvimento.
Existem 5 visões de um sistema que servem para auxiliar no desenvolvimento de um sistema de
software complexo. Cada visão destaca aspectos variados do sistema:
• Visão de Casos de Uso
• Visão de Projeto
• Visão de Implementação
• Visão de Implantação
• Visão de Processo
Quando se utiliza a UML num processo de desenvolvimento, criam-se diversos documentos que
podem ser textuais ou gráficos. Em UML, eles são denominados de artefatos de software. Esses
artefatos podem ser definidos com a utilização de diagramas UML. São 13 os diagramas existentes
na UML 2.0: Diagrama de Objetos, Diagrama de classes, Diagrama de Estrutura Composta,
Diagrama de Pacotes, Diagrama de componentes, Diagrama de Implantação, Diagrama de
Atividades, Diagrama de Sequência, Diagrama de Visão Geral da Interação, Diagrama de
Temporização, Diagrama de Colaboração, Diagrama de Casos de Uso e Diagrama de Transições e
Estados.
Capítulo 2:
Desenvolver um software é uma atividade complexa. Para minimizar essa complexidade,
utilizam-se processos de desenvolvimento de software, que são metodologias que compreendem as
atividades necessárias para a construção de um produto de software.
Esses processos abordam as tarefas que devem ser feitas durante o desenvolvimento de um
software. A primeira atividade a ser realizada é o levantamento de requisitos.
O levantamento de requisitos é a atividade que os desenvolvedores em parceria com os clientes,
levantam os requisitos necessários que futuros usuários precisarão usar no sistema desenvolvido.
Geralmente os requisitos de um sistema são identificados a partir de um domínio. Domínio é a parte
do mundo real que é relevante ao sistema em desenvolvimento. A partir desse levantamento é criado
o documento de requisitos, que esclarece os diversos tipos de requisitos do sistema. As principais
seções desse documento são: Requisitos funcionais, que são as funcionalidades do sistema;
Requisitos não funcionais, que são as qualidades que o sistema deve atender; e os Requisitos
normativos, que é a declaração de restrições impostas em sobre o desenvolvimento do sistema.
A qualidade de um software é medido de acordo com a sua utilidade. E o sistema é útil quando
atende aos requisitos definidos. O documento de requisitos inclui somente as necessidades do
usuário em relação ao que sistema deve fazer. Esse documento serve como um termo de consenso
inicial entre a equipe técnica e o cliente, e pode ser usado para validar futuramente o sistema de
software construído. Além disso, os requisitos sofrem modificações ao longo do desenvolvimento
do software, porque podem surgir novos requisitos ou a alteração de requisitos preexistentes.
A segunda atividade é a análise, a partir dela, são construídos modelos para representar o sistema
a ser construído. Aqui não é levado em conta o ambiente tecnológico a se utilizado, a principal
preocupação da análise é saber o que o sistema proposto deve fazer. Os modelos feitos nessa
atividade deverão ser validados pelos clientes para assegurar que as necessidades dele sejam
atendidas pelo sistema. A fase de análise pode ser subdivida em duas subfases: análise de domínio e
análise da aplicação.
Análise de domínio tem o objetivo de identificar os objetos do mundo real que serão utilizados
pela aplicação em desenvolvimento e identificar as regras de negócio e processos de negócio
realizados pela organização. A análise de aplicação tem o objetivo de identificar objetos de análise
que o cliente não conseguiu identificar, mas que são necessários para suprir as funcionalidades do
sistema em questão. As principais ferramentas da UML para fazer análise são o diagrama de casos
de uso e o diagrama de classes.
A terceira atividade é o projeto. Nessa fase são projetados os sistemas considerando os recursos
tecnológicos existentes. Essa fase consiste em duas atividades principais: projeto de arquitetura e
projeto detalhado. A primeira compreende em distribuir as classes de objetos relacionadas do
sistema em subsistemas e seus componentes, e também distribuir esses componentes fisicamente
pelos recursos de hardware disponíveis. A segunda, são modeladas as colaborações entre os objetos
de cada módulo com o objetivo de realizar suas funcionalidades.
A quarta atividade é a implementação, é aqui que o sistema é codificado utilizando algumas
linguagens de programação.
A quinta atividade são os testes, aqui o sistema é testado diversas vezes para encontrar possíveis
erros e relatar a equipe de desenvolvimento. Os testes são realizados de forma hierárquica, ou seja,
primeiro são testados partes pequenas separadas, depois são unidas e testadas novamente até que se
englobe o sistema todo. Testes de integração são realizados após os testes de unidades, eles testam
as operações que o sistema faz para verificar possíveis falhas na comunicação entre objetos
participantes de uma interação ou na interface de algum deles. Por fim são realizados os testes de
sistemas, com objetivo de verificar se o sistema construído está em conformidade com os requisitos
levantados para ele.
A última atividade é a implantação, em que o sistema é empacotado, distribuído e instalado no
ambiente do usuário.
Uma equipe de desenvolvimento de software é composta por vários especialistas por causa da
complexidade e do tamanho desse trabalho, a seguir terá uma breve descrição de cada um dos
participantes do processo.
- Gerentes do projeto: é o profissional responsável pela gerência ou coordenação das atividades
necessárias à construção do sistema. É responsável também pelo orçamento do projeto de e pelo
acompanhamento das atividades realizadas durante o desenvolvimento.
- Analistas: é o profissional que define os requisitos do sistema a ser desenvolvido e que se
comunica com os especialistas de domínio para extrair as necessidades do sistema e repassar esse
entendimento para os desenvolvedores do sistema.
- Projetistas: a funções de um projetista são avaliar as alternativas de solução do problema
resultante da análise, e gerar a especificação de uma solução computacional detalhada.
- Arquitetos de software: esse profissional elabora a arquitetura do sistema como um todo. É ele
que decide sobre quais subsistemas compõem o sistema e quais são as interfaces entre eles.
- Programadores: são responsáveis pela implementação do sistema, isto significa que eles
programam o sistema em uma ou mais linguagens de programação.
- Especialistas do domínio: é o cliente que possui o conhecimento sobre a área ou o negócio em
que o sistema em desenvolvimento será inserido. É primordial a participação dos especialistas do
domínio no processo de desenvolvimento.
- Avaliadores de qualidade: são eles que garantem a qualidade de um produto de software.
O desenvolvimento de um sistema envolve diversas fases, e o agrupamento dessas fases é
chamado de Modelo de ciclo de vida. Há vários modelos, mas veremos somente o modelo em
cascata e o modelo interativo e incremental.
O modelo de ciclo de vida em cascata é o modelo em que as fases são sequenciais. Porém, devido
à complexidade dos sistemas atuais, esse modelo é pouco usado porque é necessário que algumas
atividades sejam feitas em paralelo, e uma versão final do sistema irá demorar muito para ser
entregue seguindo esse modelo. Assim sendo, os modelos mais usados atualmente são os que usam
a abordagem incremental e iterativa.
O modelo de ciclo de vida incremental e iterativo foi proposto como uma resposta aos problemas
encontrados no modelo em cascata. Assim, o desenvolvimento evolui em versões, ao longo da
construção incremental e iterativa de novas funcionalidades, até que o sistema completo esteja
construído. Na verdade, um modelo de ciclo de vida iterativo e incremental pode ser visto como
uma generalização da abordagem em cascata: o software é desenvolvido em incrementos, que por
sua vez seguem o formato em cascata. Nessa abordagem, os requisitos mais arriscados são os
primeiros a serem considerados. Desse modo, se encontrar problemas nesses requisitos, eles são
corrigidos o mais cedo possível.
O ciclo de vida de processo incremental e iterativo tem duas dimensões a serem estudadas,
dimensão temporal e dimensão de atividades. A dimensão temporal engloba a concepção, a
elaboração, a construção e a transição. A dimensão de atividades são as atividades que devem ser
feitas durante o desenvolvimento de um software. Cada fase é separada por marcos, que são
descritos a seguir:
- Concepção: a ideia geral e o escopo do desenvolvimento são desenvolvidos.
- Elaboração: é alcançado um entendimento inicial sobre como o sistema será construído.
- Construção: aqui o software é construído com ocorrência de várias iterações incrementais.
- Transição: aqui os usuários são treinados para utilizar o sistema. Questões de instalação e
configuração do sistema também são tratados.
A UML é descrita como uma linguagem de modelagem independente do processo de
desenvolvimento. Ou seja, vários processos de desenvolvimento podem utilizar a UML como
ferramenta para construção dos modelos de um sistema de software orientado a objetos. Em um
modelo de ciclo de vida iterativo e incremental, os artefatos de software construídos com uso da
UML evoluem à medida que as iterações do processo são realizadas.
Uma técnica que serve de complemento á análise de requisitos é a construção de protótipos.
Servem para ser usados na validação do sistema pelo usuário com a finalidade de assegurar se os
requisitos foram bem entendidos.
Ferramentas CASE e os ambientes de desenvolvimento integrado (IDE) são algumas das
ferramentas que são utilizadas para auxiliar no ciclo de vida de desenvolvimento de um sistema. O
termo CASE é uma sigla do inglês que em português significa Engenharia de Software Auxiliada
por Computador. Existem várias ferramentas CASE no mercado. As IDEs possibilitam a
codificação do sistema com diversas facilidades como a depuração do código-fonte, a verificação de
erros em tempo de execução, a refatoração e etc.

Capítulo 3:
A UML consiste em três grandes componentes: blocos de construção básicos, regras que
restringem como esses blocos podem ser associados e mecanismos de uso geral. Os mecanismos de
uso geral será descrito a seguir.
Estereótipos são utilizados para representar um conceito. Existem dois tipos de estereótipos: os
predefinidos pela UML e os definidos pela equipe de desenvolvimento. Os estereótipos podem ser
gráficos ou textuais.
Notas explicativas são utilizadas para explicar uma parte do diagrama. Graficamente, elas são
representadas por um retângulo com uma "orelha", e este é ligado ao elemento por meio de uma
linha tracejada.
Etiquetas valoradas são utilizadas para definir outras propriedades para determinado elemento do
diagrama. São representadas dentro de chaves, que fazem parte da sintaxe.
Restrições servem para estender ou alterar a semântica natural de um elemento gráfico. Devem ser
delimitadas por chaves e devem aparecer dentro de notas explicativas.
Os pacotes são mecanismos para agrupar elementos genéricos. A notação para um pacote é a de
uma pasta com uma aba, os elementos agrupados podem ser colocados dentro da pasta ou ser
“pendurados” no ícone do pacote.
OCL é uma linguagem formal que pode ser utilizada para especificar restrições sobre diversos
elementos de um modelo. A OCL pode ser usada em qualquer diagrama da UML.

Capítulo 4:
O modelo de casos de uso (MCU) é uma representação das funcionalidades externamente
observáveis do sistema e dos elementos externos ao sistema que interagem com ele. A ferramenta da
UML utilizada na modelagem de casos de uso é o diagrama de casos de uso. O MCU é importante,
pois direciona diversas tarefas posteriores do processo de desenvolvimento de um sistema de
software.
O MCU representa os usos de um sistema, e cada um desses usos está associado a um ou mais
requisitos funcionais identificados a este sistema. Esse modelo contém 3 componentes: casos de
uso, atores e relacionamentos.
Um caso de uso é uma sequência completa de interações entre um sistema e um ou mais agentes
externos a esse sistema. No entanto, não revela a estrutura e o comportamento internos do sistema.
Cada caso de uso tem uma descrição narrativa das interações que ocorrem entre o elemento externo
e o sistema. Existem três dimensões que o estilo de descrição de um caso de uso pode variar, que
são o formato, o grau de detalhamento e o grau de abstração. Cenários são maneiras em que um
caso de uso pode ser utilizado, normalmente há diversos cenários para um mesmo caso de uso.
Os atores de um caso de uso são elementos externos que interagem com o sistema. Atores de um
sistema podem ser cargos, organizações, outros sistemas de software ou equipamentos com os quais
o sistema deve se comunicar. Geralmente o ator inicia a sequência de interações correspondente a
um caso de uso. Importante lembrar que um ator corresponde a um papel representado em relação
ao sistema.
Relacionamentos são formas de associar um ator a um caso de uso, podem também existir
associações entre atores ou entre casos de uso de um sistema. A UML define 4 relacionamentos para
o MCU: comunicação, inclusão, extensão e generalização.
O relacionamento de comunicação informa que um ator está associado com um ou mais casos de
uso. Esse relacionamento é o mais utilizado de todos.
O relacionamento de inclusão existe somente entre casos de uso. Esse relacionamento serve para
dizer que um caso de uso inclusor, obrigatoriamente, inclui o comportamento de um caso de uso
incluso.
O relacionamento de extensão serve para incluir um caso de uso que pode ser usado
opcionalmente, ou seja, um comportamento que só ocorre sob certas condições ou quando é uma
escolha do ator.
O relacionamento de generalização pode existir entre dois casos de uso ou entre dois atores. Esse
relacionamento possibilita que um caso de uso (ou um ator) herde características de outro, mais
genérico, que é normalmente chamado de caso de uso (ou ator) base. O caso de uso (ou ator)
herdeiro pode especificar o comportamento do caso de uso (ou ator) base.
O diagrama de casos de uso (DCU) corresponde a uma visão externa de alto nível do sistema, ele
representa graficamente os atores, casos de uso e relacionamentos entre esses elementos. Para
ilustrar atores em um DCU é utilizado um boneco com o nome do ator definido abaixo da figura.
Cada caso de uso é representado por uma elipse com o nome do caso de uso dentro. Um
relacionamento de comunicação é representado por um segmento de reta ligando o ator com o caso
de uso. É possível também representar a fronteira do sistema no diagrama, com um retângulo em
que os casos de uso estão dentro e os atores são posicionados do lado de fora.
Um relacionamento de inclusão em que um caso de uso A inclui um caso de uso B, é representado
por uma seta tracejada com um include escrito em cima direcionada de A para B.
Um relacionamento de extensão em que um caso de uso A estende um caso de uso B, é
representado por uma seta tracejada com um extend escrito em cima direcionada de A para B.
Uma generalização é representado por uma seta que parte do caso uso filho para o caso de suo pai.
Para construir um modelo coerente com as reais necessidades dos futuros usuários, é ideal termos
conhecimento de técnicas e boas práticas de modelagem.
Para começar a construir o MCU, todos os atores do sistema devem ser identificados , assim
sendo, o analista de sistemas deve tentar identificar quais as fontes de informações a serem
processadas e quais são os destinos das informações geradas pelo sistema. Um ator é todo elemento
externo que interage com o sistema, as fontes e os destinos das informações a serem processadas
são atores em potencial.
Na identificação dos casos de uso, existem dois tipos: primário e secundário. Os casos de uso
primário são aqueles que representam os objetivos dos atores. Esses casos de uso representam os
processos da empresa que estão sendo automatizados pelo sistema de software. Os casos de uso
secundário são aqueles que não trazem benefício direto para os atores, mas que é necessário para
que o sistema funcione adequadamente.
O objetivo principal de um sistema é produzir algo de valor para o ambiente no qual está
implantado.
Um objetivo importante do MCU é o da comunicação. Ele deve ser de fácil leitura para que
especialistas de domínio e desenvolvedores discutam as funcionalidades do sistema e o seu
comportamento. Entretanto, sistemas complexos comportam muitos casos de uso, que impede de
fazer um MCU de fácil leitura. Nessa situação, o modelador pode agrupar casos de uso logicamente
relacionados, utilizando pacotes para que o MCU possa ser compreendido e gerenciado por partes.
A documentação de atores é relativamente simples, uma breve descrição para cada ator deve ser
adicionada ao modelo de casos de uso.
Na documentação dos casos de uso, a UML não define uma estruturação específica a ser utilizada
na descrição de um caso de uso. Portante há diversas propostas de descrição. A seguir é apresentado
uma sugestão de descrição de um caso de uso expandido. Esses itens são usados de acordo com a
necessidade, ou seja, pode ser que uma equipe de desenvolvimento não precise utilizar todos.
• Nome: é o primeiro item que deve constar na descrição de um caso de uso. É o mesmo nome
utilizado no DCU.
• Identificador: é um código único para cada caso de uso que permite fazer referência cruzada entre
diversos documentos relacionados ao MCU.
• Importância: a definição da categoria de importância é atribuída ao caso de uso.
• Sumário: uma pequena declaração do objetivo do ator ao utilizar o caso de uso.
• Ator primário: o nome do ator que inicia o caso de uso.
• Atores secundários: os nomes dos demais elementos externos participantes do caso de uso.
• Pré-condições: são condições obrigatórias para a realização de um caso de uso.
• Fluxo Principal: é a descrição da sequência de passos que normalmente acontece quando o caso
de uso é utilizado.
• Fluxos alternativos: é a descrição da situação em que o ator opta por utilizar o caso de uso de uma
forma diferente da descrita no fluxo principal.
• Fluxos de exceção: esse fluxo descreve o que acontece quando há um erro na interação entre ator
e caso de uso.
• Pós-condições: é o estado que o sistema fica depois de um caso de uso ser realizado.
• Regras do negócio: a descrição de um caso de uso pode fazer a referência cruzada a uma ou mais
regras do negócio.
• Histórico: esse item pode declarar informações como o autor do caso de uso, a data em que ele foi
criado, além de eventuais modificações no seu conteúdo.
• Notas de implementação: nesse item são colocadas algumas ideias do modelador referentes à
implementação.
O MCU captura somente os requisitos funcionais, outros tipos de requisitos como regras de
negócio, requisitos de interface, requisitos de desempenho e etc, não são considerados pelo modelo
de casos de uso. A seguir será brevemente descrito como esses itens podem estar relacionados ao
modelo de casos de uso.
Regras de negócio são políticas, condições ou restrições que devem ser consideradas na execução
dos processos existentes em uma organização. Essas regras são normalmente identificadas nas fases
de levantamento de requisitos de análise e documentadas no chamado modelo de regras de negócio.
As regras do negócio geralmente têm influência sobre a lógica de execução de um ou mais casos
de uso.
Os requisitos de desempenho também não são considerados no MCU. Um requisito de
desempenho define características relacionadas à operação do sistema.
A especificação dos requisitos de um sistema pode conter também uma seção que descreva os
requisitos de interface de um sistema, como a cor, estilo, interatividade etc.
É possível planejar e realizar as interações do desenvolvimento, dividindo os casos de uso em
grupos. Cada grupo é alocado a uma iteração e, assim, cada iteração desenvolve um grupo de casos
de uso. É importante considerar os casos de uso mais arriscados primeiro.

Capítulo 5:
Para ter uma visão interna do sistema, onde os objetos do sistema colaboram uns com os outros
para produzir os resultados visíveis de fora, é utilizado o Modelo de Classes. Esse modelo
representa o aspecto estrutural estático, ele permite compreender como o sistema está estruturado
internamente para que as funcionalidades externamente visíveis sejam produzidas.
A ferramenta da UML utilizada para representar o aspecto estrutural estático é o diagrama de
classes. O modelo de classes é composto desse diagrama e da descrição textual associada ao
mesmo.
O modelo de classes é utilizado durante a maior parte do desenvolvimento iterativo e incremental
de um SSOO (Sistema de Software Orientado a Objetos). Há três estágios sucessivos de abstração
pelos quais o modelo de classes passa: análise, especificação e implementação. Porém, o foco
principal deste capítulo é o modelo de classes de análise.
O modelo de classes de análise é construído na fase de análise, sem considerar restrições
específicas à tecnologia a ser utilizada na solução de um problema. Esse modelo representa
conceitos do domínio do problema. A participação do especialista do domínio é primordial para a
correta construção do modelo de classes de análise.
O diagrama de classes é aplicado na construção do modelo de classes desde o nível de análise até
o nível de especificação. Esse diagrama é o que mais possui termos de notação.
Uma classe é representada por uma “caixa” com três compartimentos. No primeiro compartimento
é exibido o nome, no segundo, são declarados os atributos, que são informações que um objeto
armazena e, no terceiro, são declaradas as operações, que são às ações que um objeto sabe realizar.
No diagrama de classes, para representar um relacionamento entre objetos, são utilizados
associações. Uma associação é simbolizada no diagrama por uma linha ligando as classes às quais
pertencem os objetos relacionados. Associações possuem diversas características importantes:
multiplicidades, nome, direção de leitura, papéis, tipo de participação e conectividade.
A multiplicidade indica quantos objetos aos quais outro objeto pode estar associado. Essa
multiplicidade é representado por símbolos, uma em cada extremidade da linha. O símbolo "1"
mostra que um objeto está associado a somente 1 objeto; "0..*" significa que um objeto pode ter
zero ou mais objetos ligados; "1..*" significa um ou muitos; "0..1" significa zero ou um, e também
pode ter um intervalo entre dois números simbolizados com "1i..1s", em que o 1i representa o
número mínimo e o 1s, o número máximo.
A participação indica se uma associação é necessária ou não. A participação pode ser obrigatória
ou opcional, se o valor mínimo da multiplicidade é igual a 1, significa que a participação é
obrigatória, senão, é opcional.
Para esclarecer o significado de uma associação no diagrama de classes, a UML define três
recursos de notação: nome de associação, direção de leitura e papel. Sempre que o significado de
uma associação for difícil de entender, é recomendável representar papéis ou, pelo menos, o nome
da associação.
Classes associativas são classes que estão ligadas a associações. Este tipo de classe é utilizado
quando é necessário manter informações de uma associação. Na UML, classes associativas são
representadas pela mesma notação utilizada para uma classe comum, porém, está ligada em uma
associação através de uma linha tracejada.
Associações ternárias são quando uma associação liga três classes .
Uma associação reflexiva liga objetos da mesma classe. Cada objeto tem um papel distinto nessa
associação. Uma autoassociação indica que um objeto de uma classe se associa com outros objetos
da mesma classe.
Dos significados que uma associação pode ter, há uma categoria que representa relações todo-
parte. Esse tipo de relação indica que um deles está contido no outro. Na UML, existem dois tipos
dessa relação, a agregação e a composição. Graficamente, uma agregação é representada como uma
linha que conecta as classes relacionadas, com um losango branco perto da classe que representa o
todo. Já uma composição, é representada por um losango negro. Não há grandes diferenças entre a
agregação e a composição. Na agregação, a destruição de um objeto todo não implica
necessariamente a destruição do objeto parte. Na composição, os objetos parte pertencem a um
único todo.
Além de relacionamentos entre objetos, o modelo de classes também pode representar
relacionamentos entre classes, que é chamado de generalização ou especialização. O
relacionamento de herança é um tipo de generalização. No diagrama de classes, a herança é
representada na UML por uma flecha partindo da subclasse (classe herdeira) em direção à
superclasse (classe base). Assim, as subclasses herdarão as características e relacionamentos da
superclasse.
Outro tipo de diagrama estrutural que a UML define é o diagrama de objetos. Este diagrama pode
ser visto como uma instância do diagrama de classes. Assim como o diagrama de classes, os de
objetos são estruturas estáticas, elas exibem uma "fotografia" do sistema em certo momento. Nesse
diagrama, cada objeto é representado por um triângulo com dois compartimentos. No
compartimento superior, a identificação do objeto é exibida, no inferior, aparecem valores para os
atributos definidos na classe objeto.
Uma das tarefas mais importantes e difíceis no desenvolvimento de um SSOO é a identificação
das classes necessárias e suficientes para compor esse sistema. Essa tarefa se divide em duas
atividades. A primeira é identificar as classes candidatas, ou seja, entidades que podem se tornar
classes. A segunda é eliminar classes que não são necessárias.
Uma das técnicas para identificar classes é a Análise Textual de Abbott (ATA). Nessa técnica, é
utilizado diversas fontes de informação sobre o sistema: documentos de requisitos, modelos de
negócio, glossários, conhecimento do domínio etc. Assim, os nomes que aparecem nesses
documentos (substantivos e adjetivos) são destacados e, depois, os sinônimos são removidos. Dessa
forma, cada termo remanescente se enquadra em uma das situações a seguir: o termo se torna uma
classe; o termo se torna um atributo; o termo não tem relevância alguma com relação aos requisitos
do SSOO.
Também pode-se usar essa proposta para identificar operações de uma classe e associações entre
elas. Para isso, são destacados os verbos no texto. Verbos com sentido de ação são operações em
potencial, verbos com sentido de “ter” são agregações ou composições em potencial, verbos com o
sentido de “ser” são generalizações em potencial e, os demais verbos são associações em potencial.
Outra técnica para identificação de classes é a chamada Análise de casos de uso. Essa técnica é
um caso particular da ATA. Na análise de casos de uso, o MCU é utilizado como ponto de partida,
porque, para se obter o comportamento de um caso de uso, é preciso que um conjunto de objetos
colaborem. Dessa forma, o modelador que aplica essa técnica tenta identificar as classes necessárias
para produzir o comportamento que está documentado na descrição do caso de uso.
Existem também técnicas baseadas em responsabilidades, em que as diversas responsabilidades
de um SSOO são atribuídas a classes.
A técnica de projeto dirigido por responsabilidades, a ênfase está na identificação de classes a
partir de seus comportamentos relevantes para o sistema. Uma responsabilidade de um objeto é uma
obrigação que ele tem para com o sistema no qual está inserido. Em alguns casos, um objeto pode
pedir a ajuda de outros objetos para cumprir com uma responsabilidade.
A técnica de projeto dirigido ao domínio (DDD) é uma abordagem que foi apresentada por Eric
Evans em seu livro para desenvolvimento de sistemas de software complexos por meio do uso de
padrões e de boas práticas de modelagem e desenvolvimento. O ponto de partida do DDD é a
construção de um modelo do domínio que corresponde a uma representação abstrata do domínio de
aplicação no qual se insere o sistema de software a ser desenvolvido.
Conforme o DDD, o modelo de domínio deve ser construído em conjunto por especialistas do
domínio e desenvolvedores de software. Ademais, essa construção deve usar uma linguagem
universal para melhorar a comunicação entre os envolvidos. O DDD apresenta também o conceito
de projeto estratégico, que são estratégias adequadas para usar quando há muitos modelos de
domínio.
O livro de Eric Evans traz o conceito de padrão tático. Cada padrão tático corresponde a um
conjunto de famílias de classes nas quais, para cada classe pertencente a uma família, espera-se que
ela cumpra com um conjunto pré-estabelecido de responsabilidades. Os principais padrões táticos
do DDD são: entidades, objetos valor, agregados, fábricas, repositórios e serviços.
Entidade é um objeto que representa um conceito do domínio da aplicação e que possui uma
identidade única, independente dos valores de seus atributos.
Objetos valor são objetos cujo estado não pode se alterado após sua construção. Eles representam
conceitos de diferentes naturezas, como medidas, descrições, números, datas, montantes e cadeias
de caracteres.
Um agregado corresponde a classes organizadas em aglomerados, que podem envolver entidades
ou objetos valor. Em um agregado, há sempre uma classe que corresponde à raiz, por meio da qual
outros objetos podem manipular os demais objetos desse agregado.
Fábricas são objetos do domínio cuja responsabilidade é criar objetos de entidade ou objetos
valor.
Um repositório é uma classe que representa uma coleção de entidades, agregados ou mesmo de
objetos valor. Elas servem para guardar objetos de certo tipo, sem considerar aspectos tecnológicos,
e também servem para responder a consultas que solicitam subconjuntos específicos da coleção de
objetos do domínio nele armazenada.
Serviços de domínios são utilizados quando uma responsabilidade não é adequada às classes já
existentes. Portanto, é criado uma classe de serviço para assumir essa responsabilidade.
A modelagem CRC (Classes, Responsabilidades e Colaboradores) é uma técnica utilizada para
auxiliar profissionais iniciantes no paradigma da orientação a objetos na identificação de classes.
Essa técnica é aplicada em uma sala com desenvolvedores e especialistas de domínio, onde tem
início uma sessão CRC. Cada pessoa recebe um cartão com uma das classes do SSOO. Assim, são
encenados um conjunto de cenários de um caso de uso. A medida que acontece as simulações, as
classes, responsabilidades e colaborações são identificadas.
Algumas dicas para atribuição de responsabilidades: associar responsabilidades com base na
especialidade da classe, distribuir a inteligência do sistema, agrupar as responsabilidades
conceitualmente relacionadas e evitar responsabilidades redundantes.
Após a identificação de classes e responsabilidades, o modelador deve examinar as classes e fazer
as modificações necessárias. Em seguida, os analistas devem começar a definir o mapeamento das
responsabilidades e dos colaboradores de cada classe para os elementos do diagrama de classes.
Para a definição de propriedades, o modelador irá transformar as responsabilidades em atributos e
operações. Com relação às operações, elas correspondem a um modo mais detalhado de explicitar
as responsabilidades de fazer de uma classe. É recomendado fazer uma definição completa das
operações de uma classe depois da construção do modelo de interação.
Com relação aos atributos e associações, uma responsabilidade de conhecer normalmente é
mapeada para eles. Após mapear responsabilidades para atributos, deve ser verificado se cada
atributo aplica-se a todos os objetos da classe. Para criar associações, é necessário verificar os
colaboradores de uma classe, conforme identificados pela técnica de identificação dirigida a
responsabilidades. O raciocínio para definir associações reflexivas, ternárias e agregações é o
mesmo.
Identificados as classes e suas responsabilidades e colaboradores, esses elementos devem ser
organizados em um ou mais diagramas de classes e documentados. O conjunto de todos os
diagramas de classes e sua documentação, corresponde ao modelo de classes de análise.
Para evitar a construção de diagramas complexos, pode-se criar uma visão de classes participantes
(VCP). Um VCP é um diagrama de classes cujas instâncias participam da realização de um caso de
uso.
As construções do modelo de casos de uso e do modelo de classes são complementares entre si.
Depois da primeira versão do modelo de classes, o modelador deve retornar ao modelo de casos de
uso e verificar a consistência entre os dois modelos. Além disso, na realização de uma sessão de
identificação das classes, pode ser necessário a modificação de casos de uso preexistentes ou a
criação de novos casos de uso.

Você também pode gostar