Escolar Documentos
Profissional Documentos
Cultura Documentos
2 edio
Eduardo Bezerra Editora Campus/Elsevier
O engenheiro de software amador est sempre procura da mgica, de algum mtodo sensacional ou ferramenta cuja aplicao promete tornar trivial o desenvolvimento de software. uma caracterstica do engenheiro de software profissional saber que tal panacia no existe -Grady Booch
Tpicos
Introduo Diagrama de classes Diagrama de objetos Tcnicas para identificao de classes Construo do modelo de classes Modelo de classes no processo de desenvolvimento
Introduo
As funcionalidades de um SSOO so realizadas internamente atravs de colaboraes entre objetos.
Externamente, os atores visualizam resultados de clculos, relatrios produzidos, confirmaes de requisies realizadas, etc. Internamente, os objetos colaboram uns com os outros para produzir os resultados.
Essa colaborao pode ser vista sob o aspecto dinmico e sob o aspecto estrutural esttico. O modelo de objetos representa o aspecto estrutural e esttico dos objetos que compem um SSOO. Dois diagramas da UML so usados na construo do modelo de objetos:
diagrama de classes diagrama de objetos
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
Introduo
Na prtica o diagrama de classes bem mais utilizado que o diagrama de objetos.
Tanto que o modelo de objetos tambm conhecido como modelo de classes.
Objetivo: descrever o problema representado pelo sistema a ser desenvolvido, sem considerar caractersticas da soluo a ser utilizada. um dicionrio visual de conceitos e informaes relevantes ao sistema sendo desenvolvido. Duas etapas:
modelo conceitual (modelo de domnio). modelo da aplicao.
Projeto (Especificao) Venda Pagamento -quantia: Currency +getValor(): Currency 1 Pago-por 1 -data:Date -hora:Time +getTotal():Currency
8
Classes
Uma classe descreve esses objetos atravs de atributos e operaes.
Atributos correspondem s informaes que um objeto armazena. Operaes correspondem s aes que um objeto sabe realizar.
10
11
Associaes
Para representar o fato de que objetos podem se relacionar uns com os outros, utilizamos associaes. Uma associao representa relacionamentos (ligaes) que so formados entre objetos durante a execuo do sistema. Note que, embora as associaes sejam representadas entre classes do diagrama, tais associaes representam ligaes possveis entre os objetos das classes envolvidas.
12
13
Multiplicidades
Representam a informao dos limites inferior e superior da quantidade de objetos aos quais outro objeto pode se associar. Cada associao em um diagrama de classes possui duas multiplicidades, uma em cada extremo da linha de associao.
Nome Apenas Um Zero ou Muitos Um ou Muitos Zero ou Um Intervalo Especfico Simbologia na UML 1..1 (ou 1) 0..* (ou *) 1..* 0..1 li..ls
14
Exemplos (multiplicidade)
Exemplo
Pode haver um cliente que esteja associado a vrios pedidos. Pode haver um cliente que no esteja associado a pedido algum. Um pedido est associado a um, e somente um, cliente.
Exemplo
Uma corrida est associada a, no mnimo, dois velocistas Uma corrida est associada a, no mximo, seis velocistas. Um velocista pode estar associado a vrias corridas.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
15
Conectividade
A conectividade corresponde ao tipo de associao entre duas classes: muitos para muitos, um para muitos e um para um. A conectividade da associao entre duas classes depende dos smbolos de multiplicidade que so utilizados na associao.
Conectividade Um para um Um para muitos Em um extremo 0..1 1 0..1 1 No outro extremo 0..1 1 * 1..* 0..*
* * 1..* 1..* Princpios de Anlise e Projeto de Sistemas com UML - 2 edio 0..* 0..*
16
Exemplo (conectividade)
17
Participao
Uma caracterstica de uma associao que indica a necessidade (ou no) da existncia desta associao entre objetos. A participao pode ser obrigatria ou opcional.
Se o valor mnimo da multiplicidade de uma associao igual a 1 (um), significa que a participao obrigatria Caso contrrio, a participao opcional.
18
19
Classe associativa
uma classe que est ligada a uma associao, em vez de estar ligada a outras classes. normalmente necessria quando duas ou mais classes esto associadas, e necessrio manter informaes sobre esta associao. Uma classe associativa pode estar ligada a associaes de qualquer tipo de conectividade. Sinnimo: classe de associao
20
21
Associaes n-rias
Define-se o grau de uma associao como a quantidade de classes envolvidas na mesma. Na notao da UML, as linhas de uma associao n-ria se interceptam em um losango. Na grande maioria dos casos prticos de modelagem, as associaes normalmente so binrias. Quando o grau de uma associao igual a trs, dizemos que a mesma ternria.
Uma associao ternria so uma caso mais comum (menos raro) de associao n-ria (n = 3).
22
23
Associaes reflexivas
Tipo especial de associao que representa ligaes entre objetos que pertencem a uma mesma classe.
No indica que um objeto se associa a ele prprio.
Quando se usa associaes reflexivas, a definio de papis importante para evitar ambigidades na leitura da associao.
Cada objeto tem um papel distinto na associao.
24
Agregaes e Composies
A semntica de uma associao corresponde ao seu significado, ou seja, natureza conceitual da relao que existe entre os objetos que participam daquela associao. De todos os significados diferentes que uma associao pode ter, h uma categoria especial de significados, que representa relaes todo-parte. Uma relao todo-parte entre dois objetos indica que um dos objetos est contido no outro. Podemos tambm dizer que um objeto contm o outro. A UML define dois tipos de relacionamentos todo-parte, a agregao e a composio.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
25
Agregaes e Composies
Algumas particularidades das agregaes/composies:
so assimtricas, no sentido de que, se um objeto A parte de um objeto B, o objeto B no pode ser parte do objeto A. propagam comportamento, no sentido de que um comportamento que se aplica a um todo automaticamente se aplica s suas partes. as partes so normalmente criadas e destrudas pelo todo. Na classe do objeto todo, so definidas operaes para adicionar e remover as partes.
Se uma das perguntas a seguir for respondida com um sim, provavelmente h uma agregao onde X todo e Y parte.
X tem um ou mais Y? Y parte de X?
26
Exemplos
27
Agregaes e Composies
As diferenas entre a agregao e composio no so bem definidas. A seguir, as diferenas mais marcantes entre elas. Destruio de objetos
Na agregao, a destruio de um objeto todo no implica necessariamente na destruio do objeto parte.
Pertinncia
Na composio, os objetos parte pertencem a um nico todo.
Por essa razo, a composio tambm denominada agregao nocompartilhada.
Em uma agregao, pode ser que um mesmo objeto participe como componente de vrios outros objetos.
Por essa razo, a agregao tambm denominada agregao compartilhada.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
28
29
30
31
Generalizaes e Especializaes
O modelador tambm pode representar relacionamentos entre classes.
Esses denotam relaes de generalidade ou especificidade entre as classes envolvidas. Exemplo: o conceito mamfero mais genrico que o conceito ser humano. Exemplo: o conceito carro mais especfico que o conceito veculo.
32
Generalizaes e Especializaes
Terminologia
subclasse X superclasse. supertipo X subtipo. classe base X classe herdeira. classe de especializao X classe de generalizao. ancestral e descendente (herana em vrios nveis)
33
Semntica da Herana
Subclasses herdam as caractersticas de sua superclasse
como se as caractersticas da superclasse estivessem definidas tambm nas suas subclasses Alm disso, essa herana transitiva e anti-simtrica
34
Herana de Associaes
No somente atributos e operaes, mas tambm associaes so herdadas pelas subclasses. No exemplo abaixo, cada subclasse est associada a Pedido, por herana.
35
Propriedades da Herana
Transitividade: uma classe em uma hierarquia herda propriedades e relacionamentos de todos os seus ancestrais.
Ou seja, a herana pode ser aplicada em vrios nveis, dando origem a hierarquia de generalizao. uma classe que herda propriedades de uma outra classe pode ela prpria servir como superclasse.
Assimetria: dadas duas classes A e B, se A for uma generalizao de B, ento B no pode ser uma generalizao de A.
Ou seja, no pode haver ciclos em uma hierarquia de generalizao.
36
Propriedades da Herana
37
Classes Abstratas
Usualmente, a existncia de uma classe se justifica pelo fato de haver a possibilidade de gerar instncias da mesma
Essas so as classes concretas.
Subclasses de uma classe abstrata tambm podem ser abstratas, mas a hierarquia deve terminar em uma ou mais classes concretas.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
38
39
Se algum subconceito (subconjunto de objetos) atenda a tem algum(ns) das critrios acima, a criao de uma subclasses deve ser considerada. Sempre se assegure de que se trata de um relacionamento do tipo -um: X um tipo de Y?
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
40
Regra da Substituio: sejam duas classes A e B, onde A uma generalizao de B. No pode haver diferenas entre utilizar instncias de B ou de A, do ponto de vista dos clientes de A.
41
42
43
Diagrama de objetos
Alm do diagrama de classes, A UML define um segundo tipo de diagrama estrutural, o diagrama de objetos. Pode ser visto com uma instncia de diagramas de classes Representa uma fotografia do sistema em um certo momento.
exibe as ligaes formadas entre objetos conforme estes interagem e os valores dos seus atributos. Exemplo Pedido umPedido: Pedido
45
46
47
Apesar de todas as vantagens que a OO pode trazer ao desenvolvimento de software, um problema fundamental ainda persiste: identificar corretamente e completamente objetos (classes), atributos e operaes.
49
Tcnicas de Identificao
Vrias tcnicas (de uso no exclusivo) so usadas para identificar classes:
1. Categorias de Conceitos 2. Anlise Textual de Abbott (Abbot Textual Analysis) 3. Anlise de Casos de Uso
Categorizao BCE
50
Categorias de Conceitos
Estratgia: usar uma lista de conceitos comuns.
Conceitos concretos. Por exemplo, edifcios, carros, salas de aula, etc. Papis desempenhados por seres humanos. Por exemplo, professores, alunos, empregados, clientes, etc. Eventos, ou seja, ocorrncias em uma data e em uma hora particulares. Por exemplo, reunies, pedidos, aterrisagens, aulas, etc. Lugares: reas reservadas para pessoas ou coisas. Por exemplo: escritrios, filiais, locais de pouso, salas de aula, etc. Organizaes: colees de pessoas ou de recursos. Por exemplo: departamentos, projetos, campanhas, turmas, etc. Conceitos abstratos: princpios ou idias no tangveis. Por exemplo: reservas, vendas, inscries, etc.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
51
52
53
54
55
56
Categorizao BCE
Na categorizao BCE, os objetos de um SSOO so agrupados de acordo com o tipo de responsabilidade a eles atribuda.
objetos de entidade: usualmente objetos do domnio do problema objetos de fronteira: atores interagem com esses objetos objetos de controle: servem como intermedirios entre objetos de fronteira e de entidade, definindo o comportamento de um caso de uso especfico.
57
Objetos de Entidade
Repositrio para informaes e as regras de negcio manipuladas pelo sistema.
Representam conceitos do domnio do negcio.
Caractersticas
Normalmente armazenam informaes persistentes. Vrias instncias da mesma entidade existindo no sistema. Participam de vrios casos de uso e tm ciclo de vida longo.
Exemplo:
Um objeto Pedido participa dos casos de uso Realizar Pedido e Atualizar Estoque. Este objeto pode existir por diversos anos ou mesmo tanto quanto o prprio sistema.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
58
Objetos de Fronteira
Realizam a comunicao do sistema com os atores.
traduzem os eventos gerados por um ator em eventos relevantes ao sistema eventos de sistema. tambm so responsveis por apresentar os resultados de uma interao dos objetos em algo inteligvel pelo ator.
59
Objetos de Controle
So a ponte de comunicao entre objetos de fronteira e objetos de entidade. Responsveis por controlar a lgica de execuo correspondente a um caso de uso. Decidem o que o sistema deve fazer quando um evento de sistema ocorre.
Eles realizam o controle do processamento Agem como gerentes (coordenadores, controladores) dos outros objetos para a realizao de um caso de uso.
Traduzem eventos de sistema em operaes que devem ser realizadas pelos demais objetos.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
60
A categorizao BCE uma receita de bolo para identificar objetos participantes da realizao de um caso de uso.
61
Em uma VCP, so representados objetos de fronteira, de entidade e de controle para um caso de uso particular. Uma VCP definida atravs da utilizao da categorizao BCE previamente descrita...vide prximo slide.
62
entidade
fronteira
controle
entidade
entidade
63
64
65
66
Padres de Anlise
Aps produzir diversos modelos para um mesmo domnio, natural que um modelador comece a identificar caractersticas comuns entre esses modelos. Em particular, um mesmo conjunto de classes ou colaboraes entre objetos costuma recorrer, com algumas pequenas diferenas, em todos os sistemas desenvolvidos para o domnio em questo.
Quantos modelos de classes j foram construdos que possuem os conceitos Cliente, Produto, Fornecedor, Departamento, etc? Quantos outros j foram construdos que possuam os conceitos Ordem de Compra, Ordem de Venda, Oramento, Contrato, etc?
67
Padres de Anlise
A identificao de caractersticas comuns acontece em conseqncia do ganho de experincia do modelador em determinado domnio de problema. Ao reconhecer processos e estruturas comuns em um domnio, o modelador pode descrever (catalogar) a essncia dos mesmos, dando origem a padres de software. Quando o problema correspondente ao descrito em um padro de software acontecer novamente, um modelador pode utilizar a soluo descrita no catlogo. A aplicao desse processo permite que o desenvolvimento de determinado aspecto de um SSOO seja feito de forma mais rpida e menos suscetvel a erros.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
68
Padres de Anlise
Um padro de software pode ento ser definido como uma descrio essencial de um problema recorrente no desenvolvimento de software.
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice
http://www.patternlanguage.com/leveltwo/ca.htm
Cada padro descreve um problema que ocorre freqentemente no nosso ambiente, e ento descreve o ncleo de uma soluo para tal problema. Esse ncleo pode ser utilizado um milho de vezes, sem que haja duas formas de utilizao iguais. Princpios de Anlise e Projeto de Sistemas com UML - 2 edio 69 Christopher Alexander
Padres de Anlise
Padres de software podem ser utilizados em diversas atividades e existem em diversos nveis de abstrao.
Padres de Anlise (Analysis Patterns) Padres de Projeto (Design Patterns) Padres Arquiteturais (Architectural Patterns) Idiomas (Idioms) Anti-padres (Anti-patterns)
70
Padres de Anlise
Um padro de software pode ento ser definido como uma descrio essencial de um problema recorrente no desenvolvimento de software. Padres de software vm sendo estudados por anos e so atualmente utilizados em diversas fases do desenvolvimento. Padres de software utilizados na fase de anlise de um SSOO so chamados padres de anlise. Um padro de anlise normalmente composto, dentre outras partes, de um fragmento de diagrama de classes que pode ser customizado para uma situao de modelagem em particular.
71
72
73
74
As responsabilidades de um SSOO devem ser alocadas aos objetos (classes) componentes do mesmo.
75
Uma responsabilidade uma obrigao que um objeto tem para com o sistema no qual ele est inserido.
Atravs delas, um objeto colabora (ajuda) com outros para que os objetivos do sistema sejam alcanados.
Na prtica, uma responsabilidade alguma coisa que um objeto conhece ou sabe fazer (sozinho ou pedindo ajuda). Se um objeto tem uma responsabilidade com a qual no pode cumprir sozinho, ele deve requisitar colaboraes de outros objetos.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
76
Responsabilidades e Colaboradores
Exemplo: considere clientes e seus pedidos:
Um objeto Cliente conhece seu nome, seu endereo, seu telefone, etc. Um objeto Pedido conhece sua data de realizao, conhece o seu cliente, conhece os seus itens componentes e sabe fazer o clculo do seu total.
Exemplo: quando a impresso de uma fatura requisitada em um sistema de vendas, vrios objetos precisam colaborar:
um objeto Pedido pode ter a responsabilidade de fornecer o seu valor total um objeto Cliente fornece seu nome cada ItemPedido informa a quantidade correspondente e o valor de seu subtotal os objetos Produto tambm colaboraram fornecendo seu nome e preo unitrio.
77
Responsabilidades e Colaboraes
Um objeto cumpre com suas responsabilidades atravs das informaes que ele possui ou das informaes que ele pode derivar a partir de colaboraes com outros objetos.
Princpios de Anlise e Projeto onde os cidados (colaboradores) so objetos. Pense em um SSOO como uma sociedade de Sistemas com UML - 2 edio 78
Modelagem CRC
A identificao dirigida a responsabilidades normalmente utiliza uma tcnica de modelagem que facilita a participao de especialistas do domnio e analistas. Essa tcnica denominada modelagem CRC (CRC modeling). CRC: Class, Responsibility, Collaboration A modelagem CRC foi proposta em 1989 por Kent Beck e Ward Cunningham.
A princpio, essa tcnica de modelagem foi proposta como uma forma de ensinar o paradigma OO a iniciantes. Contudo, sua simplicidade de notao a tornou particularmente interessante para ser utilizada na identificao de classes.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
79
Sesso CRC
Para aplicar essa tcnica, esses profissionais se renem em uma sala, onde tem incio uma sesso CRC. Uma sesso CRC uma reunio que envolve cerca de meia dzia de pessoas. Entre os participantes esto especialistas de domnio, projetistas, analistas e o moderador da sesso. A cada pessoa entregue um carto de papel que mede aproximadamente 10cm x 15cm. Uma vez distribudos os cartes pelos participantes, um conjunto de cenrios de determinado caso de uso selecionado.
Princpios de Anlise e Projeto de Sistemas com UML - 2 edio
80
Sesso CRC
Ento, para cada cenrio desse conjunto, uma sesso CRC iniciada.
(Se o caso de uso no for to complexo, ele pode ser analisado em uma nica sesso.)
81
Modelagem CRC
Normalmente j existem algumas classes candidatas para determinado cenrio.
Identificadas atravs de outras tcnicas.
A sesso CRC comea com algum dos participantes simulando o ator primrio que dispara a realizao do caso de uso. Na medida em que esse participante simula a interao do ator com o sistema, os demais participantes encenam a colaborao entre objetos que ocorre internamente ao sistema. Atravs dessa encenao dos participantes da sesso CRC, as classes, responsabilidades e colaboraes so identificadas.
82
83
Disciplina Responsabilidades 1. 2. 3. 4. Conhecer Conhecer Conhecer Conhecer seus pr-requisitos seu cdigo seu nome sua quantidade de crditos Colaboradores Disciplina
84
85
Depois disso, os analistas devem comear a definir o mapeamento das responsabilidades e colaboradores de cada classe para os elementos do diagrama de classes.
Esse mapeamento resulta em um diagrama de classes que apresenta uma estrutura esttica relativa a todas as classes identificadas como participantes da realizao de um ou mais casos de uso.
87
Definio de propriedades
Uma responsabilidade de conhecer mapeada para um ou mais atributos. Operaes de uma classe so um modo mais detalhado de explicitar as responsabilidades de fazer.
Uma operao pode ser vista como uma contribuio da classe para uma tarefa mais complexa representada por um caso de uso. Uma definio mais completa das operaes de uma classe s pode ser feita aps a construo dos diagramas de interao.
88
Definio de associaes
O fato de uma classe possuir colaboradores indica que devem existir relacionamentos entre estes ltimos e a classe.
Isto porque um objeto precisa conhecer o outro para poder lhe fazer requisies. Portanto, para criar associaes, verifique os colaboradores de uma classe.
89
90
Organizao da documentao
As responsabilidades e colaboradores mapeados para elementos do modelo de classes devem ser organizados em um diagrama de classes e documentados, resultando no modelo de classes de domnio. Podem ser associados esteretipos predefinidos s classes identificadas:
<<fronteira>> <<entidade>> <<controle>>
91
Organizao da documentao
A construo de um nico diagrama de classes para todo o sistema pode resultar em um diagrama bastante complexo. Um alternativa criar uma viso de classes participantes (VCP) para cada caso de uso. Em uma VCP, so exibidos os objetos que participam de um caso de uso. As VCPs podem ser reunidas para formar um nico diagrama de classes para o sistema como um todo.
92
94
Depois que a primeira verso do modelo de classes de anlise est completa, o modelador deve retornar ao modelo de casos de uso e verificar a consistncia entre os dois modelos.
95
96