PROJETO DE SISTEMAS ORIENTADO A OBJETOS

Prévia do material em texto

<p>Autor: Prof. Fábio Versolatto</p><p>Colaboradores: Prof. Luciano Soares de Souza</p><p>Prof. Eduardo de Lima Brito</p><p>Projeto de Sistemas</p><p>Orientado a Objetos</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Professor conteudista: Fábio Versolatto</p><p>Mestre em Engenharia de Software pelo Instituto de Pesquisas Tecnológicas (IPT) da USP, especializado em</p><p>Arquitetura, Componentização e SOA pela Universidade Estadual de Campinas (Unicamp), pós-graduado em Tecnologia</p><p>de Construção de Software Orientado a Objetos pelo Centro Universitário Senac e bacharel em Ciência da Computação</p><p>pelo Centro Universitário da FEI.</p><p>Professor do curso de Análise e Desenvolvimento de Sistemas da Universidade Paulista (UNIP), no qual leciona e</p><p>orienta os alunos no programa de Projeto Integrado Multidisciplinar.</p><p>Atua na área de pesquisa e possui publicações e participações em eventos na área de Engenharia de Software no</p><p>Brasil e no exterior, além de projetos de pesquisa aplicados à área social.</p><p>Atua em desenvolvimento de sistemas de software e possui larga experiência em sistemas estratégicos para</p><p>empresas de grande porte, com ênfase em análise de requisitos, projeto, arquitetura e desenvolvimento de soluções</p><p>de software.</p><p>© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou</p><p>quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem</p><p>permissão escrita da Universidade Paulista.</p><p>Dados Internacionais de Catalogação na Publicação (CIP)</p><p>V564p Versolatto, Fábio Rossi.</p><p>Projeto de Sistemas Orientado a Objetos. / Fábio Rossi Versolatto.</p><p>– São Paulo: Editora Sol, 2015.</p><p>152 p., il.</p><p>Nota: este volume está publicado nos Cadernos de Estudos e</p><p>Pesquisas da UNIP, Série Didática, ano XXI, n. 2-151/15, ISSN 1517-9230.</p><p>1. Engenharia de software. 2. Sistemas. 3. Tecnologia. I. Título.</p><p>CDU 681.3.02</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Prof. Dr. João Carlos Di Genio</p><p>Reitor</p><p>Prof. Fábio Romeu de Carvalho</p><p>Vice-Reitor de Planejamento, Administração e Finanças</p><p>Profa. Melânia Dalla Torre</p><p>Vice-Reitora de Unidades Universitárias</p><p>Prof. Dr. Yugo Okida</p><p>Vice-Reitor de Pós-Graduação e Pesquisa</p><p>Profa. Dra. Marília Ancona-Lopez</p><p>Vice-Reitora de Graduação</p><p>Unip Interativa – EaD</p><p>Profa. Elisabete Brihy</p><p>Prof. Marcelo Souza</p><p>Prof. Dr. Luiz Felipe Scabar</p><p>Prof. Ivan Daliberto Frugoli</p><p>Material Didático – EaD</p><p>Comissão editorial:</p><p>Dra. Angélica L. Carlini (UNIP)</p><p>Dra. Divane Alves da Silva (UNIP)</p><p>Dr. Ivan Dias da Motta (CESUMAR)</p><p>Dra. Kátia Mosorov Alonso (UFMT)</p><p>Dra. Valéria de Carvalho (UNIP)</p><p>Apoio:</p><p>Profa. Cláudia Regina Baptista – EaD</p><p>Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos</p><p>Projeto gráfico:</p><p>Prof. Alexandre Ponzetto</p><p>Revisão:</p><p>Marcilia Brito</p><p>Juliana Mendes</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Sumário</p><p>Projeto de Sistemas Orientado a Objetos</p><p>APRESENTAçãO ......................................................................................................................................................7</p><p>INTRODUçãO ...........................................................................................................................................................7</p><p>Unidade I</p><p>1 INTRODUçãO A PROJETO DE SISTEMAS ...................................................................................................9</p><p>1.1 Por que “projetar”? ..................................................................................................................................9</p><p>2 O PROJETO NO CICLO DE VIDA DA ENGENHARIA DE SOFTwARE ............................................... 11</p><p>2.1 A fase de projetos ................................................................................................................................. 11</p><p>2.2 Por que modelar? ................................................................................................................................. 14</p><p>2.3 Conceitos do projeto ........................................................................................................................... 15</p><p>2.3.1 Abstração ................................................................................................................................................... 15</p><p>2.3.2 Modularidade ........................................................................................................................................... 16</p><p>2.4 Fases de projeto .................................................................................................................................... 18</p><p>2.5 Aspectos humanos da fase de projetos ....................................................................................... 20</p><p>2.6 O que buscamos atingir no projeto? ............................................................................................ 22</p><p>2.7 Introdução ao projeto orientado a objetos ............................................................................... 26</p><p>Unidade II</p><p>3 TECNOLOGIA DE APOIO AO PROJETO ORIENTADO A OBJETOS ..................................................... 34</p><p>3.1 A UML ........................................................................................................................................................ 34</p><p>3.2 Ferramentas de modelagem UML .................................................................................................. 39</p><p>3.3 As ferramentas CASE .......................................................................................................................... 40</p><p>3.4 Tecnologia back-end ........................................................................................................................... 43</p><p>3.5 Tecnologia front-end .......................................................................................................................... 47</p><p>3.5.1 Linguagens OO, um breve comparativo ......................................................................................... 49</p><p>4 PASSANDO DA ANÁLISE AO PROJETO .................................................................................................... 50</p><p>4.1 Desenvolver o modelo de classes de projeto refinando o modelo conceitual ............ 51</p><p>4.1.1 Modelo conceitual .................................................................................................................................. 51</p><p>4.1.2 Modelo de projeto .................................................................................................................................. 52</p><p>4.1.3 Modelo de implementação ................................................................................................................. 54</p><p>4.2 Atividades clássicas para passagem da análise para o projeto .......................................... 55</p><p>4.2.1 Detalhamento dos aspectos dinâmicos do sistema .................................................................. 55</p><p>4.2.2 Refinamento dos aspectos estáticos e estruturais do sistema ............................................ 61</p><p>4.2.3 Definição de outros aspectos da solução ..................................................................................... 63</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade III</p><p>5 PROJETOS DE DADOS E CLASSES E PROJETO ARQUITETURAL ...................................................... 70</p><p>5.1 Projeto de dados e classes ................................................................................................................ 70</p><p>5.1.1 Introdução ao projeto de dados ....................................................................................................... 70</p><p>5.1.2 Introdução a banco de dados relacionais ..................................................................................... 72</p><p>5.1.3 Bancos de dados</p><p>caso de uso</p><p>Visão	lógica</p><p>Visão	de</p><p>implementação</p><p>Visão	de	processo</p><p>Visão	de</p><p>implantação</p><p>Figura 6 – Visões da UML</p><p>Visão de caso de uso</p><p>Tem	como	objetivo	capturar	as	funcionalidades,	os	requisitos,	e	seu	comportamento	sob	a	ótica	do</p><p>usuário	final,	ou	dos	atores.</p><p>A	visão	de	caso	de	uso	é	centralizada,	uma	vez	que	o	que	é	produzido	nessa	visão	é	a	base	para	as</p><p>outras	visões	do	sistema.</p><p>Visão lógica</p><p>Também	chamada	de	visão	de	projeto	ou	visão	de	classe,	tem	como	objetivo	representar	como	as</p><p>funcionalidades	serão	implementadas	sob	o	aspecto	da	solução	de	projeto.</p><p>Representa	a	estrutura	estática	de	um	sistema,	seus	componentes	e	o	relacionamento	entre	eles</p><p>e	 como	 esses	 interagem	 para	 resolver	 um	 determinado	 problema.	 Essa	 interação	 é	 capturada	 pela</p><p>estrutura dinâmica do sistema.</p><p>Visão de processo</p><p>Também	chamada	de	visão	de	concorrência,	a	visão	de	processo	tem	como	objetivo	capturar	aspectos</p><p>de	paralelismo	de	execução	de	atividades	sob	o	ponto	de	vista	não	funcional	de	um	sistema.</p><p>A	 visão	 de	 processo	 representa	 uma	 visão	 mais	 técnica	 do	 sistema	 tratada	 como	 unidades	 de</p><p>processos	e	processamentos,	que	podem	ocorrer	de	forma	síncrona	ou	paralela.	Essas	unidades	também</p><p>podem ser interpretadas como subsistemas.</p><p>Visão de implementação</p><p>Também	 chamada	 de	 visão	 de	 componentes,	 a	 visão	 de	 implementação	 tem	 como	 objetivo</p><p>representar	aspectos	físicos	necessários	para	a	construção	do	sistema	e	como	eles	interagem	e	fazem</p><p>interface com o sistema.</p><p>37</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>São	exemplos	desses	aspectos	físicos:	sistemas	de	software, programas e rotinas internas, bancos de</p><p>dados e bibliotecas.</p><p>Visão de implantação</p><p>Também	chamada	de	visão	de	organização,	tem	como	objetivo	representar	a	organização	física	de	hardware</p><p>do	sistema,	como	computadores,	servidores	e	periféricos,	e	como	eles	se	relacionam	com	o	sistema.</p><p>Essa	visão	é	utilizada	principalmente	no	processo	de	implantação,	também	chamado	de	instalação</p><p>ou	distribuição	do	sistema.</p><p>O	quadro	a	seguir	mostra	as	visões	e	os	respectivos	diagramas	da	UML	que	compõem	cada	visão.</p><p>Quadro 5 – Visões da UML x Diagramas UML</p><p>Visão Diagramas</p><p>Visão	de	caso	de	uso</p><p>Diagrama de caso de uso</p><p>Diagrama de processo</p><p>Diagrama	de	atividade</p><p>Visão	lógica</p><p>-	Estrutura	estática:</p><p>Diagrama de classe</p><p>Diagrama	de	objeto</p><p>- Estrutura dinâmica:</p><p>Diagrama de estado</p><p>Diagrama	de	sequência</p><p>Diagrama	de	colaboração</p><p>Diagrama	de	interação</p><p>Diagrama	de	atividade</p><p>Visão	de	processo São	utilizados	os	mesmos	diagramas	utilizados	na	visão</p><p>lógica,	mas	com	ênfase	na	linha	de	execução	do	sistema.</p><p>Visão	de	implementação Diagrama de componentes</p><p>Visão	de	implantação Diagrama	de	implantação</p><p>Na	fase	de	análise	trabalhamos	com	mais	ênfase	na	visão	de	caso	de	uso,	desenvolvendo	os	diagramas</p><p>de	caso	de	uso,	de	processo	e	de	atividade,	além	de	trabalhar	com	os	diagramas	de	classe	e	sequência</p><p>sob	o	aspecto	de	conhecimento	do	domínio.</p><p>Já	na	fase	de	projetos	daremos	ênfase	à	visão	lógica,	bem	como	à	visão	de	implementação	e	à	de</p><p>implantação,	que	são	as	visões	e,	consequentemente,	os	diagramas	que	dão	suporte	à	modelagem	do</p><p>aspecto	solução	dos	requisitos	elicitados	nas	demais	visões.</p><p>É	importante	que	tenhamos	em	mente	exatamente	quais	diagramas	nos	estão	disponíveis	para	uso</p><p>e exatamente o que estamos querendo representar quando do uso de um ou de outro, e para isso é</p><p>importante	gravar	o	Quadro	5.</p><p>38</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Outro	aspecto	 importante	que	devemos	 levar	em	consideração	na	adoção	de	um	diagrama	para</p><p>representar	algo	é	a	natureza	desse	diagrama:	se	ele	representa	uma	visão	estática	ou	dinâmica.</p><p>O	modelo	estrutural	estático	representa	a	coleção	desses	objetos,	seus	atributos,	métodos	e	seus</p><p>relacionamentos,	no	entanto	as	formas	pelas	quais	eles	interagem	para	resolver	um	problema	não	pode</p><p>ser	visualizada	em	um	diagrama	de	classes,	tampouco	em	um	diagrama	de	objetos.</p><p>A	 visão	 estrutural	 dinâmica,	 também	 chamada	 de	 visão	 comportamental,	 tem	 como	 objetivo</p><p>representar	a	interação	dos	objetos	para	atingir	um	determinado	objetivo;	essa	interação	se	dá	ao	longo</p><p>de	uma	linha	de	tempo.</p><p>Observação</p><p>O	 modelo	 estrutural	 dinâmico	 é	 originado	 do	 modelo	 estático.	 Não</p><p>existe	 comportamento	 dinâmico	 que	 não	 tenha	 sido	 representado	 nos</p><p>diagramas	de	classe	ou	de	objeto.	Qualquer	tipo	de	alteração	no	modelo</p><p>dinâmico	acarreta	mudança	no	estático	e	vice-versa.</p><p>A	 figura	 a	 seguir	 mostra	 a	 estrutura	 dos	 diagramas	 da	 UML,	 com	 base	 em	 Booch,	 Jacobson	 e</p><p>Rumbaugh	(2006,	p.	96-9).</p><p>Diagrama	de	objetos</p><p>Diagrama de pacotes</p><p>Diagrama de</p><p>implantação</p><p>Diagrama de</p><p>colaboração</p><p>Diagrama	de	atividades</p><p>Diagrama de</p><p>máquina	de	estado</p><p>Diagrama de classes</p><p>Diagrama de</p><p>componentes</p><p>Diagrama de</p><p>sequência</p><p>Diagrama de</p><p>implementação</p><p>Diagrama de</p><p>caso de uso</p><p>Diagrama de</p><p>interação</p><p>Diagramas</p><p>estruturais</p><p>Diagramas UML</p><p>Diagramas</p><p>comportamentais</p><p>Figura 7 – Diagramas estruturais e comportamentais da UML</p><p>39</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Neste	 livro-texto	 iremos	 dar	 ênfase	 aos	 seguintes	 diagramas	 estruturais:	 diagrama	 de	 classes,</p><p>diagrama	 de	 pacotes,	 diagrama	 de	 componentes	 e	 diagrama	 de	 implantação.	 Além	 dos	 diagramas</p><p>comportamentais:	diagrama	de	máquina	de	estado,	diagrama	de	sequência	e	diagrama	de	colaboração.</p><p>3.2 Ferramentas de modelagem UML</p><p>Como	já	vimos,	a	UML	é	uma	coisa	e	as	ferramentas	de	modelagem	que	têm	como	base	a	UML	são</p><p>outra coisa.</p><p>Neste caso, as ferramentas agem como grandes facilitadoras para o uso da UML.</p><p>Um	 dos	 grandes	 desafios,	 dada	 a	 imensa	 variedade	 de	 ferramentas	 de	 modelagem	 disponíveis</p><p>atualmente	no	mercado,	é	escolher	qual	ferramenta	deve	ser	usada	para	modelar	o	projeto	do	sistema.</p><p>Durante	a	fase	de	projeto	chega	a	hora	de	adotar	uma	ferramenta	de	modelagem,	e	alguns	aspectos</p><p>importantes	devem	ser	considerados:</p><p>•	 A	ferramenta	está	efetivamente	de	acordo	com	a	UML?</p><p>•	 A	ferramenta	está	atualizada	com	a	UML	2.0?</p><p>•	 A	 ferramenta	é	de	uso	 livre,	ou	 seja,	 sem	custos?	Sendo	 livre,	 existe	alguma	 limitação	de	uso</p><p>(como	limite	de	quantidade	de	diagramas	ou	limite	de	quantidade	de	classes)?</p><p>•	 A	 ferramenta	 possui	 recursos	 de	 engenharia	 reversa?	 Esses	 recursos	 são	 limitados	 a	 alguma</p><p>linguagem?	As	linguagens	oferecidas	estão	de	acordo	com	as	suas	necessidades?</p><p>Observação</p><p>Engenharia	reversa	é	o	nome	que	se	dá	à	capacidade	da	ferramenta	de</p><p>modelagem	de	gerar	código-fonte	a	partir	de	diagramas	e	vice-versa.</p><p>Todos	 esses	 pontos	 são	 extremamente	 importantes	 quando	 da	 seleção	 de	 uma	 ferramenta	 de</p><p>modelagem,	principalmente,	porque	existem	inúmeras	e	incontáveis	ferramentas	disponíveis.</p><p>O	bônus	da	grande	variedade	de	ferramentas	está	no	amplo	leque	de	escolhas	que	o	projetista	terá,</p><p>e	quanto	maior	a	concorrência	entre	as	ferramentas,	maior	é	a	qualidade	do	produto	final.</p><p>O	ponto	negativo	está	relacionado	à	própria	UML.	Por	se	tratar	de	um	padrão	de	linguagem	aberto,</p><p>qualquer	um	pode	seguir	a	especificação,	desenvolver	sua	própria	ferramenta	e	disponibilizá-la	para	a</p><p>comunidade.</p><p>40</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>No entanto, existem muitas ferramentas de boa qualidade e um grande número de ferramentas de</p><p>qualidade	duvidosa.</p><p>Portanto	é	essencial	a	realização	de	uma	grande	pesquisa	antes	da	adoção	de	uma	ferramenta	de</p><p>modelagem;	é	importante	realizar	um	mapeamento	e	verificar	em	que	nível	a	ferramenta	se	encaixa	nas</p><p>características	anteriormente	citadas.</p><p>Segue	uma	relação	de	algumas	ferramentas	que	existem	no	mercado:</p><p>•	 Enterprise	Architect.</p><p>•	 Rational	Rose.</p><p>•	 Visual	Paradigm.</p><p>•	 Astah.</p><p>•	 StarUML.</p><p>Saiba mais</p><p>Pesquise	e	veja	uma	lista	de	ferramentas	de	modelagem	em:</p><p>.</p><p>O StarUML é uma ferramenta gratuita que pode ser baixada no site:</p><p>.</p><p>3.3 As ferramentas CASE</p><p>O	objetivo	da	engenharia	de	software	é	apoiar	o	desenvolvimento	de	software a partir de técnicas</p><p>para	especificar,	projetar,	manter	e	gerir	um	sistema	de	software	(SOMMERVILLE,	2010).	Ela	é	baseada</p><p>em	três	pilares:	métodos,	ferramentas	e	processos.</p><p>Ferramentas,	de	qualquer	natureza,	são	utilizadas	na	engenharia	para	dar	suporte	ou	auxiliar,	na</p><p>execução	de	uma	ou	mais	atividades.</p><p>CASE	 é	 o	 acrônimo	 em	 inglês	 para	 Computer-Aided	 Software	 Engineering,	 ou	 em	 português:</p><p>Engenharia	de	Software Auxiliada	por	Computador.</p><p>41</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Sommerville	(2010,	p.	512),	define	CASE	como	“o	processo	de	desenvolvimento	de	software com uso</p><p>de	suporte	automatizado”.</p><p>Pressman	(2006)	segue	a	mesma	linha	e	define	CASE	como	um	sistema	de	software	que	dá	suporte</p><p>a	profissionais	da	engenharia	de	software	em	todas	as	atividades	do	processo	de	software.</p><p>Huang	 (1998)	 sai	 um	pouco	da	 linha	de	Pressman	 (2006)	definindo	CASE	 como	um	produto	de</p><p>software que	dá	suporte	a	uma	ou	mais	atividades	do	processo	de	software,	enquanto	Pressman	(2006)</p><p>defende	que	uma	ferramenta	CASE	deva	dar	suporte	a	todas	as	atividades	do	processo.</p><p>Qualquer	que	seja	a	definição,	todos	convergem	para	a	mesma	linha	de	pensamento,	que	é	justamente</p><p>a	oposta	do	que	muitos	adotam	quando	falamos	em	ferramenta	CASE,	pois	uma	ferramenta	destas	não</p><p>serve	apenas	para	desenho	de	diagramas.</p><p>Ferramentas	CASE	são	classificadas	de	acordo	com	a	sua	funcionalidade	dentro	do	processo;	seguem</p><p>alguns exemplos.</p><p>•	 Ferramentas	para	planejamento	de	projetos.</p><p>•	 Ferramentas	para	gerenciamento	de	projetos.</p><p>•	 Ferramentas	para	análise	e	projeto.</p><p>•	 Ferramenta	para	construção	(desenvolvimento).</p><p>•	 Ferramentas	para	integração	de	testes.</p><p>Algumas	de	suas	principais	características:</p><p>•	 Criação	de	diagramas	e	manutenção	da	consistência	entre	esses	diagramas.</p><p>•	 Engenharia	reversa:	geração	de	código	a	partir	de	diagramas	e	vice-versa.</p><p>•	 Gerenciamento	de	versão.</p><p>•	 Gerenciamento	de	mudança.</p><p>•	 Testes	automáticos,	verificação	e	relatórios.</p><p>Precisamos	 ter	 algo	 muito	 claro	 em	 mente:	 essas	 ferramentas	 têm	 como	 único	 objetivo	 apoiar</p><p>o processo de software,	 e	 não	 substituí-lo.	 Elas	 devem	 ser	 usadas	 em	 conjunto	 com	 o	 processo	 de</p><p>engenharia	de	software.</p><p>Sendo	assim,	 todas	as	 ferramentas	CASE	devem	ser	 integradas	ao	processo	e	consequentemente</p><p>entre si.</p><p>42</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Por	 exemplo,	um	diagrama	de	 classes	gerado	na	 fase	de	análise,	 ou	 seja,	 com	o	auxílio	de	uma</p><p>ferramenta	de	modelagem	UML	(conforme	vimos	anteriormente),	é	utilizado	como	base	para	o	diagrama</p><p>de	classes	que	será	gerado	na	fase	de	projeto.</p><p>Neste	caso,	um	diagrama	não	substitui,	mas	complementa	o	outro.	Logo,	eles	passam	a	ter	uma</p><p>relação,	na	qual	uma	alteração	ou	mudança	em	um	necessariamente	se	refletirá	no	outro;	assim,	temos</p><p>algumas	necessidades	implícitas	a	esse	cenário,	como:	gerenciamento	de	dependência	e	gerenciamento</p><p>de	versão.</p><p>A	mesma	linha	de	pensamento	podemos	usar	na	relação	de	diagrama	e	descrição	de	caso	de	uso,</p><p>com	os	artefatos	produzidos	na	fase	de	projetos;	consequentemente,	esses	artefatos	devem	ter	relação</p><p>com	o	código-fonte	produzido	na	construção,	que,	por	sua	vez,	possui	relação	com	os	planos	de	testes,</p><p>e assim por diante.</p><p>A	forma	de	integração	das	ferramentas	CASE,	e	não	somente	sua	simples	adoção,	é	fator	fundamental</p><p>para	o	sucesso	do	projeto,	mas	não	somente	isso.</p><p>Pfleeger	 (2004,	p.	 27)	mostra	que	apenas	a	 integração	do	processo	à	 ferramenta	não	garante	o</p><p>sucesso	do	projeto.	A	autora	afirma	que	durante	um	longo	período,	fabricantes	dessas	ferramentas	se</p><p>esforçaram	para	vender	a	ideia	de	que	apenas	“ferramentas	padronizadas	e	integradas	em	ambientes	de</p><p>desenvolvimento,	melhorariam	o	desenvolvimento	de	software”.</p><p>A	palavra-chave	para	a	melhoria	no	desenvolvimento	de	software a partir do uso de ferramentas</p><p>CASE	 é	 “maturidade”.	 Apenas	 a	 maturidade	 do	 ambiente	 CASE	 associada	 à	 maturidade	 da	 equipe</p><p>aumenta	o	fator	de	produtividade	(PLEEGER,	2004.	p.	89).</p><p>Nós,	enquanto	analistas	e	projetistas,	devemos	estar	atentos	quando	do	momento	da	adoção	de</p><p>uma	ferramenta	CASE	em	um	de	nossos	projetos,	uma	vez	que,	como	vimos,	é	importante,	na	fase	de</p><p>projetos,	que	tenhamos	suporte	e	rastreabilidade	dos	artefatos	produzidos	na	análise,	dos	que	serão</p><p>produzidos	no	projeto	e	ainda	do	que	será	efetivamente	construído.</p><p>O	trabalho	de	Tsuda	et al.	(1992)	mostra	um	pouco	dessa	realidade,	discutindo	alguns	fatores	que</p><p>levam	ao	aumento	da	produtividade	com	a	adoção	de	ferramentas	a	partir	de	um	estudo	de	caso	de	um</p><p>cenário	real.</p><p>Uma	 frase	 do	 artigo	 de	 Brooks	 (1987,	 p.	 1),	 de	 título	 reflexivo	 No	 Silver	 Bullet:	 Essence</p><p>and Accidents of Software Engineering,	 em	 português,	 algo	 como	 “não	 existe	 bala	 de	 prata:</p><p>essência	 e	 acidentes	 da	 engenharia	 de	 software”,	 é	 ainda	 muito	 atual,	 pois	 “não	 existe	 um</p><p>único	desenvolvimento,	em	qualquer	tecnologia	ou	gestão	técnica,	que	por	si	só	prometa	uma</p><p>ordem	de	grandeza	de	melhoria	de	uma	década	em	termos	de	produtividade,	confiabilidade	ou</p><p>simplicidade”.</p><p>43</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Saiba mais</p><p>Para	aprofundar	seus	conhecimentos	sobre	avaliação	de	benchmarking</p><p>envolvendo	algumas	das	principais	ferramentas	CASE,	leia:</p><p>MAHDY.	 A.	 A.	 E-R.;	 AHMED,	 M.	 M.	 A.	 E-S.;	 ZAHRAN,	 S.	 M.	 Flexible</p><p>CASE	 tools	 for	 requirements	 engineering:	 a	 benchmarking	 survey.	 In:</p><p>INTERNATIONAL	 CONFERENCE	 OF	 INFORMATICS	 AND	 SYSTEMS,	 2008.</p><p>Proceedings...	Cairo,	2008.	Disponível	em:	.	Acesso	em:	17	abr.	2015.</p><p>Ferramentas	CASE	ou	ferramentas	de	apoio	à	engenharia	de	software podem ser classificadas em</p><p>dois grupos: front-end e back-end.</p><p>3.4 Tecnologia back-end</p><p>Tecnologias	de	apoio	ao	projeto	classificadas	como	back-end	estão	relacionadas	ao	gerenciamento	e</p><p>armazenamento	das	informações.	São	os	Sistemas	Gerenciadores	de	Banco	de	Dados	(SGBD).</p><p>Segundo	Silberschatz,	Korth	e	Sudarshan	(2006,	p.	1),	“um	sistema	de	gerenciamento	de	banco	de</p><p>dados	(DBMS)	é	uma	coleção	de	dados	inter-relacionados	e	um	conjunto	de	programas	para	acessar</p><p>esses	dados	que	tem	como	objetivo	fornecer	uma	maneira	de	recuperar	informações	de	um	banco	de</p><p>dados	de	forma	conveniente	e	eficiente”.</p><p>Observação</p><p>O	 objetivo	 desta	 disciplina	 não	 é	 se	 aprofundar	 no	 tema	 Banco	 de</p><p>Dados.	Abordaremos	apenas	aspectos	que	tangenciem	a	fase	de	análise	e</p><p>que	tenham	correlação	com	o	tema.</p><p>A	figura	a	seguir	mostra	a	evolução	do	conceito	de	banco	de	dados,	à	medida	que	cresceu	também</p><p>a	complexidade	dos	sistemas	de	informação.</p><p>Arquivos</p><p>sequenciais em</p><p>fita magnética</p><p>BD	em	rede	/</p><p>Surgimento do</p><p>SGBD</p><p>Bibliotecas</p><p>específicas	de</p><p>acesso	a	dados	/</p><p>Primeiros	BDs</p><p>BD	relacional</p><p>Banco	de	dados</p><p>orientado a</p><p>objetos	/	IA</p><p>aplicada</p><p>1ª	Geração 2ª	Geração 3ª	Geração 4ª	Geração 5ª	Geração</p><p>Aumento	da	complexidade	de	sistemas	de	informação</p><p>Figura	8	–	Evolução	dos	bancos	de	dados</p><p>44</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>A	 primeira	 geração	 dos	 repositórios	 de	 informações	 é	 marcada	 pela	 gravação	 sequencial	 das</p><p>informações	em	fita	magnética,	 sendo	de	 responsabilidade	do	programador	desenvolver	 seu	próprio</p><p>algoritmo	para	leitura	e	escrita	dessas</p><p>informações.</p><p>Na	segunda	geração	começam	a	surgir	as	primeiras	bibliotecas	de	acesso	aos	dados,	facilitando	um</p><p>pouco	o	dia	a	dia	do	desenvolvedor.	É	nessa	época	também	que	surgem	os	primeiros	esboços	de	bancos</p><p>de	dados,	que	viriam	em	substituição	às	fitas	magnéticas.</p><p>Em	seguida,	na	terceira	geração,	surgem	as	padronizações	no	acesso	a	dados,	sistemas	que	faziam</p><p>desde	o	gerenciamento	da	atualização	até	a	leitura	das	informações.	A	esses	sistemas	foi	dado	o	nome</p><p>de	Sistemas	Gerenciadores	de	Banco	de	Dados	(SGBD).</p><p>A	quarta	geração	é	aquela	na	qual	se	baseia	o	que	temos	atualmente:	consolidação	dos	SGBDs,	dos</p><p>bancos	de	dados	relacionais	e	da	linguagem	SQL.</p><p>A	quinta	geração	ainda	é	algo	 incipiente	e	que	ainda	carece	de	maior	desenvolvimento,	que	é	a</p><p>inclusão	de	banco	de	dados	orientado	a	objetos	e	a	incorporação	de	técnicas	de	inteligência	artificial	no</p><p>conceito	de	banco	de	dados	(MEDEIROS,	2013).</p><p>Na	fase	de	projetos,	e	isso	se	aplica	também	ao	paradigma	da	orientação	a	objetos,	atualmente	se</p><p>utilizam	dois	modelos	de	banco	de	dados:	o	modelo	entidade-relacionamento	e	o	modelo	orientado	a</p><p>objetos,	sendo	este	último	utilizado	em	menor	escala.</p><p>O	modelo	entidade-relacionamento	ou	E-R,	tem	como	base	a	percepção	do	mundo	real	como	um</p><p>conjunto	de	entidades	e	do	relacionamento	entre	elas.	As	entidades	são	caracterizadas	no	banco	de</p><p>dados	pelos	seus	atributos	(SILBERSCHATZ;	KORTH;	SUDARSHAN,	2006).</p><p>Similar	ao	E-R,	o	modelo	orientado	a	objetos	tem	por	base	um	conjunto	de	objetos.	Cada	objeto</p><p>possui	 um	 conjunto	 de	 características	 (atributos)	 que,	 ao	 possuírem	 um	 determinado	 conjunto	 de</p><p>valores,	passam	a	constituir	uma	identidade	para	o	objeto.</p><p>A	diferença	conceitual	do	modelo	orientado	a	objetos	para	o	E-R	está	em	alguns	pontos:</p><p>•	 No	modelo	orientado	a	objetos,	cada	objeto	possui	um	conjunto	de	códigos	que	operam	sobre</p><p>este	objeto,	chamado	de	método.</p><p>•	 Objetos	que	possuem	o	mesmo	conjunto	de	atributos	e	métodos	são	denominados	classe.</p><p>•	 Cada	objeto	possui	uma	identidade	única	independente	dos	valores	contidos	em	seus	atributos,</p><p>ou	seja,	mesmo	que	um	objeto	possua	os	mesmos	valores	dos	atributos	de	outro	objeto	no	mesmo</p><p>banco de dados, estes possuem identidades diferentes.</p><p>•	 Adoção	de	mecanismos	de	relacionamento:	composição,	agregação	e	herança.</p><p>45</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Lembrete</p><p>Os	 conceitos	 fundamentais	 do	 modelo	 orientado	 a	 objetos	 para</p><p>banco	de	dados	 são	os	mesmos	conceitos	 fundamentais	do	paradigma</p><p>da	 orientação	 a	 objetos:	 objeto,	 classe,	 métodos,	 atributos,	 herança	 e</p><p>identidade.</p><p>O	banco	de	dados	orientado	a	objetos	ainda	esbarra	em	alguns	pontos,	frutos	da	própria	incipiência</p><p>da tecnologia.</p><p>Um	desses	pontos	é	a	mistificação	do	desempenho.	A	pesquisa	de	Saxena	e	Pratap	 (2013)	é	um</p><p>exemplo	 de	 trabalho	 que	 faz	 um	 comparativo	 entre	 as	 duas	 tecnologias	 E-R	 e	 OO	 em	 um	 cenário</p><p>específico.</p><p>O	 resultado	obtido	nessa	pesquisa,	 e	 que	pode	 ser	 visto	na	figura	 a	 seguir,	 é	muito	próximo	ao</p><p>cenário	obtido	por	muitas	pesquisas	que	seguem	essa	mesma	linha:	o	desempenho	do	BD	OO	aumenta</p><p>à	medida	que	a	complexidade	do	negócio	aumenta.</p><p>+</p><p>+</p><p>-</p><p>-</p><p>Banco	de	dados	OO</p><p>Banco	de	dados	relacional</p><p>Complexidade	de	objetos</p><p>Te</p><p>m</p><p>po</p><p>d</p><p>e</p><p>re</p><p>sp</p><p>os</p><p>ta</p><p>Figura	9	–	Comparativo	de	desempenho:	banco	de	dados	OO	versus relacional</p><p>A	pesquisa	de	Saxena	e	Pratap	(2013)	chega	à	conclusão	de	que	o	tempo	de	resposta	de	um	banco</p><p>de	dados	relacional	é	maior	em	todos	os	cenários	—	atualização,	leitura	e	escrita	—	quando	o	número	de</p><p>objetos	e	a	complexidade	deles	é	baixa;	do	contrário,	se	o	número	e	a	complexidade	de	objetos	for	maior,</p><p>o	desempenho	do	banco	de	dados	orientado	a	objetos	mostrar-se-á	mais	satisfatório.</p><p>Atualmente,	em	quantidade	de	uso,	bancos	de	dados	orientados	a	objetos	possuem	números	menores</p><p>se	comparados	a	bancos	de	dados	relacionais,	e	muito	disso	se	deve	à	falta	de	maturidade	e	à	falta	de</p><p>uso	de	uma	padronização.</p><p>46</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>São	dois	os	principais	padrões	para	banco	de	dados	orientado	a	objetos:	o	padrão	Common	Object</p><p>Request	Broker	Architecture	(CORBA)	e	o	padrão	Object	Request	Broker	(ORB),	ambos	definidos	pela	OMG.</p><p>O	padrão	CORBA	define	uma	arquitetura-padrão	para	 comunicação:	 troca	de	 informações	entre</p><p>objetos	independentemente	do	produto,	hardware ou sistema operacional, garantindo a portabilidade e</p><p>a	interoperabilidade	(OMG,	2014).</p><p>Saiba mais</p><p>Para	aprofundar	seus	conhecimentos	sobre	a	especificação	CORBA,	acesse:</p><p>.</p><p>O	Object	Management	Architecture	(OMA)	define	um	padrão	arquitetural	para	gerenciamento	de</p><p>objetos	 em	 um	 modelo	 de	 dados	 em	 cujo	 centro	 está	 o	 padrão	 ORB,	 que,	 segundo	 a	 OMG	 (2014),</p><p>“fornece	uma	infraestrutura	que	permita	que	objetos	se	comuniquem	independente	das	plataformas	e</p><p>de	técnicas	específicas	utilizadas	para	implementar	os	objetos	abordados.	A	ORB	garante	portabilidade</p><p>e	interoperabilidade	dos	objetos	através	de	uma	rede	de	sistema	heterogêneo”.</p><p>Saiba mais</p><p>Sobre	a	especificação	OMA,	acesse:</p><p>OBJECT	 MANAGEMENT	 ARCHITECTURE.	 Object	 Management	 Group,</p><p>2014.	Disponível	em:	.	Acesso	em:	17	abr.	2015.</p><p>Paralelamente	 aos	 padrões	 definidos	 pela	 OMG,	 surge	 também	 o	 padrão	 definido	 pela	 Object</p><p>Data	Management	Group	(ODMG):	o	Object-oriented	Database	Management	Systems	(OODBMS),	que</p><p>também	tem	como	objetivo	definir	um	padrão	de	comunicação	entre	aplicações	orientadas	a	objetos	e</p><p>um	sistema	gerenciador	de	banco	de	dados	orientado	a	objetos	(CATTELL	et al., 2000).</p><p>Saiba mais</p><p>Saiba	mais	sobre	o	padrão	da	ODMG	em:</p><p>CATTELL,	R.	G.	et	al.	The	object	data	management	standard:	ODMG	3.0.</p><p>California:	Morgan	Kaufmann,	2000.</p><p>Ou acesse:</p><p>.</p><p>47</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Essa	falta	de	maturidade	na	padronização	ainda	não	colocou	os	principais	participantes	do	mercado</p><p>da	indústria	de	bancos	de	dados	(Microsoft,	Oracle	etc.)	com	a	força	que	se	espera	no	mercado	de	banco</p><p>de	dados	orientado	a	objetos.</p><p>A	seguir	a	lista	de	alguns	dos	principais	bancos	de	dados	orientados	a	objetos	disponíveis	atualmente:</p><p>•	 Gemstone.</p><p>•	 ObjectStore.</p><p>•	 Versant.</p><p>•	 Objectivity/DB.</p><p>•	 Easy/DB.</p><p>•	 Ontos/DB.</p><p>•	 Jasmine.</p><p>3.5 Tecnologia front-end</p><p>Tecnologias de apoio front-end	são	subdivididas	em	duas	categorias:	ferramentas	de	modelagem	e</p><p>linguagens	de	programação	OO.</p><p>As	ferramentas	de	modelagem,	voltadas	para	o	paradigma	da	orientação	a	objetos,	em	sua	maioria,</p><p>restringem-se	às	ferramentas	que	possuem	a	UML	como	base.</p><p>Lembrete</p><p>Como	 vimos,	 o	 assunto	 Ferramentas	 de	 Modelagem	 é	 extenso	 e</p><p>costumeiramente	gera	dúvidas	quanto	a	sua	relação	com	a	UML,	conforme</p><p>debatemos	nas	seções	iniciais	desta	unidade.</p><p>As	linguagens	de	programação	orientada	a	objetos	são	mecanismos	de	implementação	do	modelo</p><p>de	projeto	que	desenhamos	na	fase	de	projeto.</p><p>Analogamente	ao	exemplo	da	construção	de	uma	casa,	é	como	se	o	modelo	produzido	na	fase	de</p><p>projetos	fosse	o	nosso	conjunto	de	plantas	e	os	mecanismos	de	construção	desse	modelo	—	tijolos,	areia,</p><p>cimento,	canos	etc.	—	fossem	a	nossa	plataforma	de	desenvolvimento	orientado	a	objetos.</p><p>A	primeira	linguagem	orientada	a	objetos	pura	utilizada	para	a	construção	dentro	do	paradigma	OO</p><p>foi	a	linguagem	Smalltalk,	que	teve	seu	uso	difundido	na	década	de	1980	e	tem	importância	para	as</p><p>gerações	futuras,	pois	sua	terminologia	é	referencial	para	outras	linguagens	OO	(THE	HISTORY...,	2010).</p><p>48</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Saiba mais</p><p>Saiba	mais	sobre	a	linguagem	Smalltalk em:</p><p>.</p><p>Não	é	qualquer	linguagem	de	programação	que	pode	ser	considerada	orientada	a	objetos;	para	tal,</p><p>é	necessário	que	se	cumpram	determinados	prerrequisitos	(LEE;	TAPFENHART,	2001):</p><p>•	 Encapsulamento	de	dados	–	garantir	a	confiabilidade	e	a	capacidade	de	modificação	do	sistema	de</p><p>software,	expondo	apenas	o	necessário	ao	restante	do	sistema,	sendo	que	o	estado	de	um	objeto</p><p>deve	estar	representado	em	atributos	privados,	visíveis	apenas	no	escopo	do	próprio	objeto.</p><p>•	 Abstração	de	dados	–	a	linguagem	deve	estar	apta	a	implementar	um	tipo	abstrato	de	dados,	ou</p><p>seja,	um	conjunto	de	métodos	utilizados	para	manipular	essas	informações.</p><p>•	 Coesão	dinâmica	–	a	linguagem	deve	implementar	o	mecanismo	de	troca	de	mensagens	no	qual</p><p>existe	o	objeto	chamador,	que	envia	a	mensagem	e	o	objeto	receptor	que	recebe	a	mensagem	e</p><p>executa um método.</p><p>•	 Herança	–	permitir	a	codificação	de	classes	que	sejam	especializações	de	outras	classes.</p><p>Lee	e	Tapfenhart	(2001,	p.	31)	observam	que	as	linguagens	ditas	puras	OO,	ou	seja,	que	seguem	à</p><p>risca	todos	os	conceitos	do	paradigma	OO,	tais	como:	Object	C,	Smalltalk	e	Eiffel,	não	se	mostraram</p><p>produtivas	quanto	ao	desenvolvimento	em	larga	escala	de	sistemas	de	software para fins comerciais.</p><p>Para	tal,	foi	criada	uma	série	de	extensões	das	linguagens	ditas	puras	que	partem	do	princípio	da</p><p>extensão,	e	não	da	modificação,	na	qual,	o	programador	pode	utilizar	técnicas	não	orientada	a	objetos</p><p>quando apropriado.</p><p>Linguagens	como:	C++,	Java	e	C#	passam	a	ocupar	fatia	importante	do	mercado	de	desenvolvimento.</p><p>Saiba mais</p><p>Saiba	mais	sobre	aplicação	de	C++	em	projeto	orientado	a	objetos	em:</p><p>LEE,	R.	C;	TAPFENHART,	W.	M.	UML e C++:	guia	prático	de	desenvolvimento</p><p>orientado	a	objeto.	São	Paulo:	Makron	Books,	2001.</p><p>49</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Esta	disciplina	não	tem	como	objetivo	dar	ênfase	a	uma	linguagem	específica,	mas	faz	parte	das</p><p>habilidades	necessárias	do	arquiteto,	conforme	vimos,	o	conhecimento	aprofundado	nas	plataformas</p><p>tecnológicas,	uma	vez	que	soluções	técnicas	poderão	ser	adotadas	ou	não,	em	função	da	plataforma</p><p>escolhida.</p><p>De	qualquer	forma,	é	importante	que	nós,	neste	momento,	nos	livremos	de	alguns	mitos	e	inverdades</p><p>que	possam	limitar	erroneamente	nosso	campo	de	visão.</p><p>3.5.1 Linguagens OO, um breve comparativo</p><p>Atualmente,	quando	falamos	em	plataforma	de	desenvolvimento,	duas	das	mais	utilizadas	são:	Java</p><p>e Microsoft .NET.</p><p>Essas	 duas	 plataformas	 respondem	 por	 parcela	 significativa	 no	 mercado	 de	 desenvolvimento.</p><p>Segundo	a	pesquisa	do	Instituto	Gartner	(DRIVER,	2007),	aproximadamente	80%	das	grandes	empresas</p><p>dependem de ambas.</p><p>Essa	pesquisa	traz	resultados	interessantes,	pois	coloca	em	números	questões	sobre	esse	debate	que</p><p>muitas	vezes	envereda	pelo	lado	passional	ou	por	preferências	pessoais	às	tecnologias	A	ou	B.</p><p>Observação</p><p>O	Instituto	Gartner	é	um	importante	e	confiável	instituto	de	pesquisa</p><p>norte-americano	 especializado	 na	 análise	 de	 tendências	 do	 mercado	 de</p><p>tecnologia.</p><p>Um	dos	muitos	indicativos	interessantes	que	a	pesquisa	traz,	e	que	começa	a	derrubar	um	pouco	um</p><p>dos	principais	mitos,	está	relacionado	ao	domínio	de	mercado	por	uma	tecnologia.	Seguem	os	números</p><p>desses	indicadores	(DRIVER,	2007):</p><p>•	 Empresas	consideradas	pequenas:	70%	utilizam	Microsoft	e	menos	de	5%	utilizam	Java.</p><p>•	 Empresas	consideradas	médias:	60%	utilizam	Microsoft	e	25%	utilizam	Java.</p><p>•	 Empresas	consideradas	grandes:	25%	utilizam	Microsoft	e	50%	utilizam	Java.</p><p>Em	todos	os	intervalos	de	números	a	diferença	para	a	totalidade	é	destinada	a	outras	tecnologias,</p><p>como	4GL,	Legacy,	dentre	outros.</p><p>Outra	conclusão	 importante,	 e	que	permeia	muitas	discussões,	 está	 relacionada	à	produtividade.</p><p>Segundo	a	pesquisa,	a	produtividade	do	desenvolvedor	na	plataforma	Java	é	menor	que	a	produtividade</p><p>do	desenvolvedor	Microsoft	(DRIVER,	2007).</p><p>50</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Um	 fator	 interessante	 deste	 indicador.	 Se	 compararmos	 o	 indicador	 flexibilidade	 com	 o	 fator</p><p>produtividade,	 a	 flexibilidade	 técnica	 da	 plataforma	 Java	 será	 maior	 que	 a	 flexibilidade	 Microsoft,</p><p>com	um	detalhe:	a	produtividade	Java	versus	a	produtividade	Microsoft	e	a	flexibilidade	Java	versus a</p><p>flexibilidade	Microsoft	apresentam	indicadores	inversamente	proporcionais.</p><p>Pode-se	 concluir	 que	 ambas	 as	 plataformas	 possuem	 qualidades	 e	 defeitos	 bem	 pontuados	 e</p><p>atenuados,	de	tal	forma	que	uma	discussão	que	questione	qual	plataforma	é	melhor,	sem	uma	análise</p><p>minuciosa	 do	 cenário	 no	 qual	 será	 aplicada,	 certamente	 será	 direcionada	 para	 o	 lado	 passional	 da</p><p>discussão,	o	que	não	nos	parece	algo	relacionado	à	engenharia.</p><p>Saiba mais</p><p>Veja	mais	indicadores	em:</p><p>DRIVER,	M.	Java	and	.NET:	you	can’t	pick	a	favorite	child.	In:	DEVELOPER</p><p>SUMMIT,	2007.	Palm	Springs.	Proceedings...	Palm	Springs,	2007.	Disponível</p><p>em:	 .	Acesso	em:	22	abr.	2015.</p><p>4 PASSANDO DA ANÁLISE AO PROJETO</p><p>Como	vimos,	em	um	projeto	de	desenvolvimento	de	software temos a necessidade de representar</p><p>as	diversas	visões	desse	software	e	para	tal	nos	utilizamos	das	chamadas	visões	da	UML,	ou	visões	de</p><p>modelagem.</p><p>A	visão	central	deste	modelo	é	a	de	caso	de	uso,	que	é	a	base	de	tudo	e	que	fornece	uma	perspectiva</p><p>do software	sob	o	ponto	de	vista	do	externo	a	este	software	(negócio/ator).</p><p>Ainda	na	 fase	de	análise,	produzimos	o	modelo	de	classes	conceitual	que	representa	a	estrutura</p><p>estática	da	interação	de	objetos	para	resolver	um	determinado	problema.	Nesse	modelo	são	representados</p><p>os	atributos,	os	métodos	e	como	as	classes	se	relacionam	(herança,	ligação,	composição,	agregação).</p><p>O	diagrama	de	objetos	 também	pode	 ser	utilizado	como	complemento	ao	modelo	de	classes	de</p><p>domínio,	uma	vez	que	ele	também	representa	uma	visão	estrutural	que	pode	ser	considerada	como	uma</p><p>instância	do	diagrama	de	classes	(BEZERRA,	2006).</p><p>Na	fase	de	análise	o	modelo	de	classe	é	utilizado	para	representar	objetos	do	domínio	do	problema.</p><p>Logo,	podemos	dizer	que	o	modelo	de	casos	de	uso	somado	ao	modelo	de	classes	de	domínio	tem	por</p><p>objetivo	esclarecer	o	problema	a	ser	resolvido.</p><p>51</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Observação</p><p>Na	fase	de	projetos	utilizamos	como	 insumo	os	artefatos	produzidos</p><p>durante	 a	 fase	 de	 análise	 que,	 dentre	 outras	 atividades,	 compreende</p><p>elicitação	e	análise	dos	requisitos	do	negócio	no	qual	o	sistema	de	software</p><p>se	dispõe	a	atender	uma	necessidade	ou	resolver	um	determinado	problema.</p><p>O	 modelo	 de	 classes	 evolui	 durante	 o	 ciclo	 de	 vida	 do	 software	 e	 na	 fase	 de	 projeto	 (design) é</p><p>utilizado	para	representar	objetos	da	solução.</p><p>Se	o	modelo	de	classes	é	o	mesmo,	quando	termina	a	fase	de	análise	e	começa	a	fase	de	projetos?</p><p>Podemos	dizer	que	a	fase	de	projetos	começa	a	partir	do	momento	em	que	fechamos	a	primeira</p><p>versão	do	modelo	de	classe	de	domínio;	nesse	momento,	temos	a	transição	análise-projeto.</p><p>4.1 Desenvolver o modelo de classes de projeto refinando o modelo conceitual</p><p>A	perspectiva	dada	pelo	modelo	de	classe	de	domínio	não	é	suficiente	para	avançarmos	para	a	fase</p><p>de	implementação	(construção).	Precisamos	definir	aspectos	inerentes	à	solução	do	problema.</p><p>Há	três	perspectivas	do	modelo	de	classes:</p><p>•	 Modelo	conceitual.</p><p>•	 Modelo	de	projeto.</p><p>•	 Modelo	de	implementação.</p><p>A	seguir,	cada	modelo	será	detalhado	para	melhor	compreensão.</p><p>4.1.1 Modelo conceitual</p><p>Desenvolvido	 na	 fase	 de	 análise,	 este	 modelo	 representa	 as	 classes	 no	 domínio	 do	 negócio	 em</p><p>questão	e	não	leva	em	consideração	restrições	inerentes	à	tecnologia	a	ser	utilizada	na</p><p>solução	de	um</p><p>problema.</p><p>O modelo conceitual representa uma entidade do mundo real que possui:</p><p>•	 Identidade:	valor	de	uma	característica	que	o	identifica	para	reconhecimento.</p><p>•	 Atributos:	qualidades	e	características.</p><p>•	 	Comportamento:	habilidades	de	processamento.</p><p>52</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>4.1.2 Modelo de projeto</p><p>Também	 chamado	 de	 modelo	 de	 especificação,	 o	 modelo	 de	 projeto	 é	 desenvolvido	 na	 fase	 de</p><p>projeto	(design)	e	é	uma	evolução	do	modelo	conceitual,	no	qual	são	adicionados	detalhes	da	solução</p><p>de software.</p><p>Representa	um	objeto	do	mundo	real,	dentro	de	um	universo	de	software que contém:</p><p>•	 Identidade:	identificador	em	termos	de	implementação	(em	memória).</p><p>•	 Atributos:	os	atributos	que	definem	o	objeto	passam	a	 ter	 tipos	de	dados.	Nota-se	aqui,	uma</p><p>correlação	maior	com	a	linguagem	ou	plataforma	de	desenvolvimento	a	ser	utilizada,	uma	vez</p><p>que	os	tipos	de	dados	podem	variar	de	uma	 linguagem	para	outra,	por	exemplo,	 Int32,	 Int64,</p><p>Integer,	String,	Double,	Decimal	etc.</p><p>Saiba mais</p><p>Para	aprofundar	seus	conhecimentos	sobre	os	tipos	de	dados	presentes</p><p>no	Microsoft	.Net	Framework,	consulte	a	biblioteca:</p><p>.</p><p>Se	preferir	a	plataforma	Java,	consulte-a	em:</p><p>.</p><p>•	 Comportamento:	funções	ou	procedimentos	que	determinam	o	comportamento	do	objeto	passam</p><p>a	possuir	assinaturas.	e	é	obrigatório	que	se	defina	o	nível	de	visibilidade	dos	métodos.</p><p>Observação</p><p>A	assinatura	de	um	método,	assim	como	a	assinatura	de	uma	função</p><p>em algoritmos, é composta de: tipo de retorno + nome do método +</p><p>parâmetros de entrada (tipo de dado, nome do parâmetro).</p><p>Vamos	relembrar	alguns	pontos	importantes	sobre	visibilidade	de	atributos	e	métodos,	uma	vez	que</p><p>são	pontos	obrigatórios	na	fase	de	projetos.</p><p>Visibilidade	indica	quando	e	em	que	nível	um	atributo	ou	um	método	de	um	objeto	pode	ser	acessível</p><p>aos	objetos	que	se	relacionam	com	ele.	Em	orientação	a	objetos,	temos	três	níveis	de	visibilidade	de</p><p>atributos e métodos:</p><p>53</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>•	 Público:	o	atributo	ou	o	método	pode	ser	acessado	por	qualquer	classe.	Na	UML,	indicamos	que</p><p>um	atributo	ou	um	método	é	público	utilizando	o	sinal	+	(positivo),	conforme	exemplo	a	seguir.</p><p>Figura 10	–	Exemplo	de	representação	de	um	método	público</p><p>Ainda	de	acordo	com	a	figura	anterior,	podemos	dizer	que	o	método	efetuarSaque	pode	ser	chamado</p><p>por	qualquer	outro	objeto.</p><p>•	 Privado:	um	atributo	ou	método	privado	pode	ser	acessado	somente	na	própria	classe	em	que</p><p>está	declarado.	Na	UML,	indicamos	que	um	atributo	ou	um	método	é	privado	utilizando	o	sinal	-</p><p>(negativo),	conforme	exemplo	a	seguir.</p><p>Figura 11	–	Exemplo	de	representação	de	um	método	privado</p><p>Ainda	a	partir	da	figura	apresentada,	podemos	dizer	que	o	método	obterSaldoCC	pode	ser	chamado</p><p>apenas	dentro	da	própria	classe	Cliente.	Por	exemplo:	poderíamos	 ter	uma	chamada	a	esse	método</p><p>dentro do método efetuarSaque.</p><p>Observação</p><p>Atributos	 e	 métodos	 marcados	 como	 privado	 são	 a	 chave	 para</p><p>implementação	de	encapsulamento.</p><p>•	 Protegido:	um	atributo	ou	um	método	protegido	pode	ser	acessado	apenas	na	classe	em	que</p><p>está	declarado	e	em	suas	classes-filhas.	Na	UML,	 indicamos	que	um	atributo	ou	um	método	é</p><p>protegido	utilizando	o	sinal	#	(sustenido),	conforme	exemplo	a	seguir.</p><p>54</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Figura 12	–	Exemplo	de	representação	de	um	atributo	protegido</p><p>Podemos	dizer,	de	acordo	com	a	figura	anterior,	que	o	atributo	saldoCC	é	acessível	apenas	na	classe</p><p>Cliente	e	nas	suas	classes-filhas:	ClientePF	e	ClientePJ.</p><p>4.1.3 Modelo de implementação</p><p>O	 modelo	 de	 classes	 de	 implementação	 corresponde	 à	 implementação	 das	 classes	 em	 alguma</p><p>linguagem	de	programação,	por	exemplo,	C#	(Microsoft	 .Net	Framework)	ou	Java,	como	mostram	as</p><p>figuras a seguir.</p><p>Nestes	exemplos,	estamos	codificando	uma	classe	chamada	Cliente	que	possui	um	atributo	(saldo)</p><p>e um método (efetuarSaque).</p><p>Figura 13	–	Exemplo	de	implementação	de	classe	em	C#</p><p>55</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Figura	14	–	Exemplo	de	implementação	de	classe	em	Java</p><p>4.2 Atividades clássicas para passagem da análise para o projeto</p><p>Segundo	Bezerra	(2006),	o	objetivo	desse	momento	do	ciclo	de	vida	do	projeto	é	obter	um	nível</p><p>de	detalhamento	dos	modelos	tal	que	possamos	passá-los	para	os	desenvolvedores	implementarem	o</p><p>sistema	(modelo	de	implementação).</p><p>Observação</p><p>Um	pouco	de	vivência	prática	sobre	a	visão	do	arquiteto	e	a	codificação:	o</p><p>arquiteto	adentra	a	fase	de	construção	codificando	a	estrutura	ou	adotando</p><p>algum framework	utilizando,	dentre	outros	elementos,	padrão	de	projeto,</p><p>além	de	codificar	os	pontos	da	aplicação	considerados	fundamentais.</p><p>São	três	as	atividades	clássicas	enumeradas	por	Bezerra	(2006):	detalhamento	dos	aspectos	dinâmicos</p><p>do	sistema,	refinamento	dos	aspectos	estáticos	e	estruturais	do	sistema	e	definição	de	outros	aspectos</p><p>da	solução.</p><p>4.2.1 Detalhamento dos aspectos dinâmicos do sistema</p><p>O	objetivo	dessa	fase	é	a	representação	da	interação	dos	objetos	de	forma	dinâmica.	O	dinamismo</p><p>está	relacionado	à	representação	do	estado	e	do	comportamento	do	objeto	em	uma	linha	de	tempo.</p><p>Lembrete</p><p>O	diagrama	de	classes	representa	uma	visão	estática,	pois	não	nos	dá	o</p><p>aspecto	temporal	de	um	objeto.</p><p>Os	 modelos	 que	 representam	 os	 aspectos	 dinâmicos	 de	 um	 sistema	 são:	 modelo	 de	 interações,</p><p>modelo	de	estados	e	modelo	de	atividades;	este	último	é	o	menos	utilizado.</p><p>56</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>O	 modelo	 de	 interação	 dos	 objetos	 representa	 a	 forma	 pela	 qual	 estes	 interagem	 para</p><p>resolver	um	determinado	problema,	e,	conforme	vimos	pelo	paradigma	da	orientação	a	objetos,</p><p>a	interação	dos	objetos	se	dá	pela	troca	de	mensagens,	e	estas	são	o	centro	da	representação</p><p>desse modelo.</p><p>Antes	de	entrar	na	modelagem	das	mensagens	vamos	relembrar	os	possíveis	significados	de	uma</p><p>mensagem.</p><p>Uma	mensagem	pode	ter	três	significados	(STADZISZ,	2002):</p><p>•	 Chamada	de	função	ou	procedimento:	é	o	tipo	mais	utilizado	de	mensagem.	Significa	que	um</p><p>objeto	está	solicitando	a	execução	de	um	método	de	outro	objeto.</p><p>Neste	caso,	a	função	ou	procedimento	corresponde	a	um	método	público	em	um	objeto	que	pode</p><p>ser	acessível	a	um	objeto	“chamador”,	conforme	mostra	a	figura	a	seguir.</p><p>Figura	15	–	Exemplo	de	troca	de	mensagens:	chamada	de	função</p><p>É	 possível	 notar,	 nessa	 figura,	 que	 os	 métodos	 e	 alguns	 atributos	 das	 classes	 já	 possuem</p><p>características	do	modelo	de	projeto,	ou	seja,	tipos	de	dados	e	nível	de	visibilidade.	Além	do	mais,</p><p>57</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>as	mensagens	do	diagrama	de	sequência	devem	obrigatoriamente	refletir	os	métodos	e	a	assinatura</p><p>descritos no diagrama de classes.</p><p>•	 Envio	explícito	de	mensagem:	utilizando	um	tipo	de	serviço	bem	específico	e	especializado	para</p><p>envio	e	recebimento	de	mensagens,	por	exemplo,	Message	Queue	(fila	de	mensagens).</p><p>•	 Evento:	quando	uma	mensagem	é	enviada	para	um	objeto	do	sistema	originária	de	um	evento</p><p>externo	ao	sistema.	É	comum	que	esse	 tipo	de	mensagem	seja	próprio	da	comunicação	entre</p><p>atores	e	objetos.	Por	exemplo:	um	clique	de	mouse	pode	ser	considerado	um	evento	externo	ao</p><p>sistema	e	que	deve	ser	interpretado	por	um	objeto	interno	do	mesmo	sistema.</p><p>Além	 do	 significado	 de	 uma	 mensagem,	 ao	 detalharmos	 os	 aspectos</p><p>dinâmicos	 do	 sistema,</p><p>devemos	 entender	que	 tipo	de	mensagem	estamos	querendo	 representar,	 pois	 isso	definirá	 como	o</p><p>comportamento	do	sistema	será	construído.	Aqui	começamos	a	tratar	de	questões	importantes	de	um</p><p>sistema, por exemplo, paralelismo.</p><p>Segundo	o	padrão	de	comunicação	de	interação	de	objetos,	que	pode	ser	observado	em	Stadzisz</p><p>(2002),	existem	dois	tipos	de	mensagem	entre	objetos:</p><p>•	 Mensagens	síncronas:	são	mensagens	que	implicam	um	sincronismo	rígido	entre	os	estados	do</p><p>objeto	que	envia	a	mensagem	e	os	do	objeto	de	destino	da	mensagem.</p><p>—	Em	um	nível	de	projeto,	podemos	interpretar	que	este	tipo	de	mensagem	é	utilizado	quando	o</p><p>método	do	objeto	chamado	possui	algum	tipo	de	retorno	no	qual	o	objeto	chamador	espera.</p><p>•	 Mensagens	assíncronas:	não	há	dependência	de	estado	do	objeto	chamador	e	do	processamento</p><p>do	objeto	chamado.	O	objeto	chamador	envia	a	mensagem	e	continua	o	seu	processamento.</p><p>—	Em	um	nível	de	projeto,	utilizamos	esse	tipo	de	mensagem	quando	queremos	iniciar	algum	tipo</p><p>de	processamento	paralelo	entre	dois	objetos,	ou	seja,	o	objeto	chamador	pode	continuar	o	seu</p><p>processamento	 independentemente	do	 retorno	do	objeto	 chamado	ou	dos	processamentos</p><p>iniciados	pelo	objeto	chamado	após	o	envio	da	mensagem.</p><p>Além	de	mensagens	síncronas	e	assíncronas,	Larman	(2007)	observa	mais	alguns	tipos	de	mensagens:</p><p>•	 Autodelegação	de	mensagens:	um	objeto	pode	enviar	uma	mensagem	para	ele	mesmo,	solicitando</p><p>a	execução	de	um	método.	Esse	movimento	é	chamado	de	autodelegação.	O	método	que	só	pode</p><p>ser	chamado	pelo	próprio	objeto	que	o	contém,	conforme	vimos,	é	um	método	privado,	e	isso	é</p><p>muito	importante	levarmos	em	consideração	no	momento	do	projeto,	pois	isso	garante	o	correto</p><p>uso do encapsulamento.</p><p>•	 Criação	e	destruição	de	objetos:	no	ciclo	de	vida	de	um	objeto,	existem	dois	métodos,	construtores</p><p>e	destrutores,	que	têm	como	objetivo	criar	e	remover	um	objeto	da	estrutura	de	memória	de	um</p><p>sistema.	Em	orientação	a	objetos,	quando	um	objeto	cria	outro	para	utilizá-lo	ou	para	enviar-lhe</p><p>58</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>uma	mensagem,	dizemos	que	o	primeiro	possui	uma	referência	à	instância	do	objeto	criado	e,</p><p>na	fase	de	projeto,	é	importante	que	criemos	as	referências	apenas	quando	necessário,	pois	isso</p><p>define	a	dependência	entre	objetos	e	é	o	início	da	coesão	e	do	acoplamento.</p><p>A figura a seguir mostra os elementos de uma estrutura dinâmica que debatemos até agora, dispostos no</p><p>diagrama	de	sequência	da	UML.	O	exemplo	dessa	figura	mostra	um	processo	fictício	de	fechamento	de	notas:</p><p>Figura 16 – Exemplo de modelagem de aspectos dinâmicos de um sistema</p><p>59</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Quadro 6 – Exemplo de modelagem de aspectos dinâmicos de um sistema</p><p>Letra Descrição</p><p>A</p><p>Diagrama	de	classes,	com	inclusão	de	tipos	de	dados	nos</p><p>atributos,	assinatura	completa	nos	métodos	e	visibilidade	de</p><p>atributos e métodos.</p><p>Note	que	a	forma	pela	qual	os	métodos	estão	especificados	no</p><p>diagrama	de	classes	é	a	mesma	do	diagrama	de	sequência.</p><p>B</p><p>O	retângulo	representa	um	objeto	que	faz	parte	da	execução	do</p><p>cenário.	Note	que	estamos	falando	de	objetos,	e	não	de	classes,</p><p>pois quando estamos representando a troca de mensagens,</p><p>no	aspecto	dinâmico	do	sistema,	o	objeto	já	está	instanciado.</p><p>Obrigatoriamente,	os	objetos	do	diagrama	de	sequência	devem</p><p>constar no modelo de classes.</p><p>C</p><p>Representa	o	ator,	envolvido	no	contexto.	Como	vimos,	um	ator</p><p>pode	ser	um	elemento	externo	ao	sistema,	como	um	usuário,</p><p>um	dispositivo	de	hardware ou outro sistema.</p><p>D</p><p>O	retângulo	posicionado	abaixo	do	objeto	significa	que	naquele</p><p>espaço	de	tempo	iniciou-se	o	ciclo	de	vida	do	objeto.	Como</p><p>vimos,	um	objeto	é	criado,	utilizado	e	destruído,	e	nesse	espaço</p><p>de	tempo	representado	pelo	retângulo	o	objeto	está	ativo,	ou</p><p>seja,	está	criado,	e	está	apto	a	receber	mensagens.</p><p>E A	linha	tracejada	abaixo	dos	atores	e	dos	objetos	representa	a</p><p>linha	de	tempo.</p><p>F</p><p>A	seta	com	linha	tracejada	logo	abaixo	da	seta	com	ponta	cheia</p><p>representa um retorno de uma mensagem, retorno este de uma</p><p>mensagem	síncrona	representada	pela	seta	com	ponta	cheia.</p><p>Neste	momento,	o	objeto	do	Professor	está	aguardando	o</p><p>retorno	e	o	processamento	do	objeto	Aluno.</p><p>G</p><p>A	seta	recursiva	indica	uma	autodelegação	de	mensagem.</p><p>É	o	objeto	do	tipo	Professor	enviando	uma	mensagem	para	ele</p><p>mesmo	a	partir	do	método	privado	calcularNota.</p><p>H</p><p>A	seta	aberta	indica	o	envio	de	uma	mensagem	assíncrona.</p><p>Após	o	envio	da	mensagem	receberNota	do	objeto	do</p><p>tipo	Professor	para	o	objeto	do	tipo	Aluno,	ambos	podem</p><p>executar outros processamentos, independentemente da</p><p>resposta deste método.</p><p>Que	é	o	que	efetivamente	ocorre,	o	objeto	do	tipo	Aluno</p><p>envia	uma	mensagem	(com	significado	de	evento)	para	o	ator</p><p>Impressora,	e	o	objeto	do	tipo	Professor	envia	uma	mensagem</p><p>para	ele	mesmo:	efetuarFechamento.</p><p>É	claro	que	todo	processamento	paralelo	uma	hora	é</p><p>sincronizado	dentro	do	sistema,	por	isso	a	importância	de</p><p>modelarmos	e	especificarmos	corretamente	o	que	é	síncrono	e	o</p><p>que	é	assíncrono	na	fase	de	projeto	(design).</p><p>Na	UML,	mais	precisamente	no	diagrama	de	sequência,	ainda	podemos	representar	estruturas	de</p><p>decisão	e	repetição,	o	mesmo	conceito	que	vimos	em	algoritmos	básicos.</p><p>60</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Saiba mais</p><p>Para	 aprofundar	 seus	 conhecimentos	 sobre	 estruturas	 de	 decisão	 e</p><p>repetição,	leia:</p><p>MARTINS,	 C.	 T.	 K.;	 RODRIGUES,	 M.	 Algoritmos	 elementares	 C++.	 São</p><p>Paulo:	LCTE,	2006.</p><p>A	figura	a	seguir	mostra	um	exemplo	de	estrutura	de	decisão.	No	diagrama	de	sequência,	temos	o</p><p>elemento	operador	de	controle,	que	pode	ser	observado	no	ponto	indicado	com	a	letra	A.	O	indicativo</p><p>“alt”	no	operador	de	controle	significa	fluxo	alternativo,	ou	seja,	só	será	executado	se	uma	condição	for</p><p>satisfeita;	no	caso,	a	senha	informada	deve	ser	correta.</p><p>Figura 17	–	Exemplo	de	fluxo	alternativo	em	diagrama	de	sequência</p><p>A	seguir,	mostra-se	um	exemplo	de	laço	de	repetição.	O	indicativo	 loop no operador de controle,</p><p>indicado	pela	 letra	A,	 sinaliza	uma	 repetição:	no	caso,	 a	mensagem	 informarSenha	 será	enviada	no</p><p>mínimo	uma	vez	e	no	máximo	três	vezes,	conforme	indicado	no	operador	de	controle.</p><p>61</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Figura	18	–	Exemplo	de	estrutura	de	repetição	em	diagrama	de	sequência</p><p>Note	a	importância	de	se	modelar	corretamente	as	estruturas	de	decisão	e	de	repetição;	no	momento</p><p>em	que	o	desenvolvedor	analisar	o	modelo,	saberá	exatamente	o	que	construir,	diminuindo,	e	muito,</p><p>problemas	de	entendimento	ou	até	mesmo	problemas	de	desempenho	decorrentes	de	má	prática	de</p><p>programação.</p><p>4.2.2 Refinamento dos aspectos estáticos e estruturais do sistema</p><p>O	 refinamento	 dos	 aspectos	 estáticos	 do	 sistema	 tem	 como	 objetivo	 promover	 a	 passagem	 do</p><p>modelo	de	classes	de	domínio	para	o	modelo	de	classes	de	projetos	(BEZERRA,	2006).</p><p>O	primeiro	passo	a	ser	dado	é	detalhar	os	atributos	e	os	métodos,	pois	quando	começamos	a	associar</p><p>os tipos de dados e a complementar a assinatura dos métodos, alguns elementos podem ficar confusos,</p><p>principalmente	para	o	desenvolvedor.</p><p>Para	evitar	mal-entendido	e	efetivamente	validar	se	o	modelo	a	ser	construído	tem	relação	com</p><p>o	problema	que	pretende	resolver,	os	atributos	e	métodos	devem	ser	detalhados	quanto	ao	seu	uso	e</p><p>significado dentro do contexto do sistema.</p><p>O	 mesmo	 se	 aplica	 no	 detalhamento	 do	 relacionamento	 entre	 os	 objetos,	 que	 é	 igualmente</p><p>necessário	e	deve	ser	feito	na	sequência,	com	o	principal	objetivo	de	detalhar	os	relacionamentos</p><p>do	tipo	associação	de	objetos,	uma	vez	que	essas	relações	não	são	facilmente</p><p>absorvidas	em	um</p><p>primeiro momento.</p><p>62</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Observação</p><p>Se	 um	 objeto	 envia	 uma	 mensagem	 para	 outro,	 eles	 possuem	 uma</p><p>ligação,	chamada	de	associação	simples,	ou	seja,	uma	ligação	que	acontece</p><p>apenas em um determinado momento.</p><p>O	último	passo	para	o	 refinamento	é	a	atribuição	de	 responsabilidades	aos	objetos	da	 classe	de</p><p>domínio.</p><p>A	 atribuição	 de	 responsabilidades	 está	 relacionada	 aos	 atributos	 e	 métodos	 dessa	 classe.</p><p>Devemos	verificar	se	o	objeto	é	suficientemente	autocontido	ou	se,	eventualmente,	não	possui	mais</p><p>responsabilidades	do	que	deveria,	o	que	causaria	uma	baixa	coesão	no	universo	sistêmico.</p><p>Uma	 classe	 do	 modelo	 de	 domínio	 pode	 gerar	 uma	 ou	 mais	 classes	 do	 modelo	 de	 projetos	 e</p><p>vice-versa.	Não	existe	uma	regra	para	isso,	tudo	depende	do	cenário	que	estamos	modelando.</p><p>A	divisão	de	responsabilidades	é	uma	das	características	fundamentais	em	uma	boa	modelagem	de</p><p>sistemas.	Objetos	com	responsabilidades	bem-definidas	aumentam	a	sua	capacidade	de	reúso.</p><p>Organizar	e	dividir	os	objetos	por	responsabilidade	é	a	base	para	o	conceito	de	padrões	de	projeto,</p><p>que	vem	a	ser	um	conjunto	de	soluções	e	organização	sistêmica	com	um	objetivo	específico.</p><p>No	caso,	a	divisão	de	responsabilidades	pode	ser	encarada	como	um	padrão	de	projeto	com</p><p>o	 objetivo	 de	 aumentar	 o	 reúso	 e	 diminuir	 o	 acoplamento	 entre	 objetos	 de	 um	 sistema.	 Esse</p><p>conceito	 é	 a	 base	 para	 o	 padrão	 de	 projeto	 Model-View-Controller	 (MVC),	 que	 veremos	 com</p><p>maiores	detalhes.</p><p>Quando	estamos	definindo	as	responsabilidades	dos	objetos	dentro	do	sistema,	passamos	a	identificar</p><p>as classes de entidade, de fronteira e de controle.</p><p>Entidade</p><p>Uma	entidade,	classe	de	entidade	ou	ainda	objeto	de	entidade	são	objetos	mais	próximos	do	domínio</p><p>do	mundo	real	que	o	sistema	representa,	são	abstrações	do	mundo	real	que	normalmente	conseguimos</p><p>identificar nos casos de uso.</p><p>Esses	objetos	têm	como	objetivo	principal	manter	informações	referentes	ao	domínio	de	problema</p><p>que	queremos	resolver.</p><p>Nas	classes	de	entidade,	representamos	informações	e	comportamentos	que	são,	de	alguma	forma,</p><p>armazenados	no	sistema.	Por	exemplo:	dentro	do	domínio	do	nosso	problema	de	saque	em	terminal	de</p><p>autoatendimento, temos as classes de entidade cliente, cartão e terminal de autoatendimento.</p><p>63</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Fronteira</p><p>Classes	de	fronteira	ou	objetos	de	fronteira,	como	o	próprio	nome	diz,	têm	como	responsabilidade</p><p>dividir	o	ambiente	interno	do	sistema	e	suas	interações	externas.</p><p>Podemos	 interpretar	 interações	 externas	 a	um	 sistema	 como	 toda	 e	 qualquer	 comunicação</p><p>que	um	sistema	faz	com	atores	do	sistema	ou	ainda	alimentar	 informações	de	outros	sistemas.</p><p>Por	exemplo:	dentro	do	domínio	do	nosso	problema	de	saque,	o	sistema	deve	se	comunicar	com</p><p>outro	sistema,	externo,	responsável	por	efetuar	a	autenticação	de	segurança	da	senha	de	acesso</p><p>do cliente.</p><p>Outros	exemplos	clássicos	de	interface	externa:	envio	de	informações	para	sistemas	governamentais,</p><p>como	informações	fiscais;	consumo	de	informações	de	outros	sistemas,	como	informações	de	crédito;</p><p>interface	com	SGBD.</p><p>Lembrete</p><p>Na	 fase	 de	 análise	 do	 ciclo	 de	 vida	 da	 engenharia	 de	 software, na</p><p>atividade	 de	 modelagem	 de	 casos	 de	 uso,	 atores	 de	 um	 sistema	 são</p><p>agentes	 externos	 ao	 sistema,	 que	 executam	 determinada	 ação	 e	 que</p><p>esperam	 algum	 resultado,	 podendo	 ser	 um	 usuário,	 um	 dispositivo	 de</p><p>hardware ou outro sistema.</p><p>Controle</p><p>Classes	 de	 controle,	 objetos	 de	 controle	 ou	 ainda	 controladores	 são	objetos	 que	 têm	 como</p><p>objetivo	realizar	o	sequenciamento	da	execução	de	um	caso	de	uso	na	estrutura	de	objetos	do</p><p>sistema,	bem	como	fazer	a	coordenação	entre	as	camadas	internas	do	sistema,	representadas	pelas</p><p>classes de entidade, com as camadas externas ao sistema, representadas pelas classes de fronteira.</p><p>Alguns	autores	também	chamam	esse	movimento	de	orquestração.</p><p>4.2.3 Definição de outros aspectos da solução</p><p>A	definição	de	outros	aspectos	da	solução	passa	para	um	nível	arquitetural	do	processo	de	passagem</p><p>da	fase	de	análise	para	a	fase	de	projetos.	Com	o	modelo	de	classes	de	projeto	pronto,	começamos	a</p><p>pensar	em	como	organizar	essas	classes	da	melhor	forma.</p><p>O	primeiro	passo	a	ser	dado	é	a	decomposição	do	sistema	em	subsistemas,	ou	também	chamados</p><p>de	componentes;	esse	é	o	processo	de	componentização	de	um	sistema	de	software	(BEZERRA,	2006).</p><p>Analogamente,	 e	 também	 superficialmente,	 é	 como	 a	 indústria	 eletrônica	 já	 trabalha	 há	 muito</p><p>tempo.</p><p>64</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Cada	componente	eletrônico	é	um	conjunto	de	CIs	(circuitos	integrados),	e	cada	qual	possui	uma</p><p>finalidade	dentro	do	componente.	Em	um	sistema	eletrônico,	apenas	os	componentes	conversam	entre</p><p>si	por	interfaces	de	comunicação	bem	definidas,	não	existe	comunicação	entre	os	CIs.	Desta	forma,	cada</p><p>componente em um sistema eletrônico funciona como uma unidade autônoma nesse sistema.</p><p>A	 componentização	 na	 indústria	 eletrônica	 promove	 alguns	 benefícios,	 dentre	 eles:	 maior</p><p>produtividade,	 pois	 é	 possível	 que	 equipes	 trabalhem	 em	 paralelo,	 uma	 vez	 que	 as	 interfaces	 de</p><p>comunicação	já	estão	definidas;	e	manutenibilidade,	pois	é	possível	que	se	substitua	um	componente</p><p>do	sistema	(por	falha	ou	evolução)	sem	que	o	todo	seja	desestruturado.</p><p>A	 indústria	 eletrônica	 está	 mais	 avançada	 que	 a	 de	 software	 nesse	 quesito,	 todavia	 o	 nível	 de</p><p>maturidade	das	corporações	e	a	especialização	dos	profissionais	já	mostram	promissores	fatores	para	a</p><p>mudança	deste	cenário.</p><p>Saiba mais</p><p>O	 assunto	 componentização	 é	 extenso	 e	 deve	 ser	 aprofundado</p><p>na	forma	de	especialização.	O	tema	é	muito	valorizado	e	tem	grande</p><p>mercado	de	atuação;	referências	no	assunto:</p><p>HEINEMAN	 G.	 T.;	 COUNCILL,	 W.	 T.	 Component-based	 software</p><p>engineering:	putting	the	pieces	together.	Boston:	Addison-Wesley	Longman</p><p>Publishing,	2001.</p><p>SZYPERSKI,	 C.	 Component	 software:	 beyond	 object-oriented</p><p>programming.	2.	ed.	Boston:	Addison-Wesley	Longman	Publishing,	2002.</p><p>Componentes	definidos,	devemos	especificar	e	modelar	como	distribuiremos	esses	componentes	nos</p><p>recursos de hardware	que	possuímos.</p><p>Atualmente,	muitos	são	os	recursos	disponíveis	para	distribuição	do	software, por exemplo, sistemas</p><p>distribuídos	em	rede,	serviços	web (ou Web	Services),	cloud computing etc. Trataremos com maiores</p><p>detalhes	sobre	como	representamos	essa	distribuição,	nas	próximas	unidades.</p><p>Ainda	 sobre	 a	 definição	 de	 outros	 aspectos	 da	 solução,	 devemos	 definir	 como	 os	 objetos	 serão</p><p>persistidos	em	um	repositório	de	informações.</p><p>O	ato	de	definir	como	e	quais	objetos	serão	persistidos	em	um	repositório	tem	grande	relação	com	o</p><p>modelo	de	dados	adotado	para	o	SGBD,	ou	seja,	qualquer	que	seja	o	modelo	adotado,	E-R	ou	orientado</p><p>a	objetos,	deve-se	 refletir	e	planejar	 sobre	 isso	neste	momento.	 Trataremos	esse	assunto	com	maior</p><p>aprofundamento	nas	próximas	unidades.</p><p>65</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Com	 relação	 a	 essas	 três	 atividades,	 da	 passagem	 da	 análise	 ao	 projeto,	 é	 importante	 que</p><p>tenhamos	em	mente	que	elas	não	são	executadas	de	forma	linear	em	um	único	sentido,	ou	seja,</p><p>todos	os	modelos	produzidos	 em	cada	atividade	poderão,	 e	 deverão,	 ser	 refinados	 sempre	que</p><p>houver	necessidade.</p><p>Isso	quer	dizer	que	um	modelo	de	classes	de	projeto	poderá	e	deverá	ser	alterado	se,	no	momento</p><p>da	modelagem	dos	aspectos	dinâmicos,	for	encontrada	alguma	anomalia,	assim	como	o	próprio	modelo</p><p>de	análise,	se	preciso	for.	Isso</p><p>é	extremamente	importante	nesta	fase	do	ciclo	de	vida	do	projeto.</p><p>Resumo</p><p>Nesta unidade tratamos de dois temas centrais: a tecnologia de</p><p>apoio	ao	projeto	orientado	a	objetos	e	a	transição	da	fase	de	análise</p><p>para	a	fase	de	projeto.</p><p>Sobre	o	tema	da	tecnologia	de	apoio	ao	projeto	orientado	a	objetos,</p><p>vimos	que	boa	parte	desse	suporte	é	baseado	na	UML.</p><p>Embora	muitos	ainda	confundam	algumas	coisas,	vimos	que	a	UML</p><p>não	é	uma	tecnologia,	nem	um	software, nem uma ferramenta ou uma</p><p>linguagem	de	desenvolvimento.</p><p>A	UML	é	uma	 linguagem	de	modelagem	unificada,	utilizada	para</p><p>representar	as	diversas	visões	de	um	software durante o seu ciclo de</p><p>vida	de	desenvolvimento.</p><p>Um software,	 segundo	 Kruchten	 (1995)	 e	 Booch,	 Jacobson	 e</p><p>Rumbaugh	(2006),	possui	cinco	visões:	visão	lógica,	visão	de	processo,</p><p>visão	de	implementação,	visão	de	implantação	e	visão	de	caso	de	uso,</p><p>sendo	esta	última	a	central,	ou	seja,	a	que	fornece	subsídios	para	todas</p><p>as	visões.</p><p>Cada	 visão	 possui	 uma	 finalidade	 bem-definida,	 logo	 cada	 uma</p><p>possui	um	conjunto	de	diagramas	da	UML	específicos	para	cada	uma</p><p>dessas	finalidades.	Antes	de	utilizarmos	a	UML	a	esmo,	precisamos	ter	a</p><p>noção	de	qual	visão	estamos	querendo	modelar	e	de	quais	os	diagramas</p><p>corretos para cada finalidade.</p><p>Para	 desenharmos	 os	 diagramas	 da	 UML,	 utilizamos	 como</p><p>facilitadores	 as	 ferramentas	 de	 modelagem,	 todavia	 vimos	 que	 a</p><p>adoção	e	o	uso	consciente	de	uma	ferramenta	de	mercado	são	fatores</p><p>fundamentais	para	o	sucesso	nessa	fase	do	projeto.</p><p>66</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Outra	tecnologia	de	apoio	ao	projeto	são	as	chamadas	ferramentas</p><p>CASE,	que	têm	como	objetivo	apoiar	todo	o	ciclo	de	vida	da	engenharia</p><p>de software,	e	não	somente	uma	fase	específica.</p><p>Todavia,	a	simples	adoção	de	uma	ferramenta	CASE	também	não</p><p>é	garantia	de	qualidade	e	 sucesso	no	projeto.	As	 ferramentas	CASE</p><p>utilizadas	 no	 projeto	 devem	 estar	 interligadas	 e,	 principalmente,</p><p>devem	 ter	 um	 modelo	 de	 processo	 de	 desenvolvimento	 sólido	 e</p><p>maduro como suporte.</p><p>As tecnologias de apoio OO podem ser classificadas como back-end e</p><p>front-end.</p><p>Tecnologias back-end	basicamente	são	as	tecnologias	relacionadas	ao</p><p>armazenamento	e	gerenciamento	de	informações;	são	os	chamados	SGDBs,</p><p>ou	Sistemas	Gerenciadores	de	Bancos	de	Dados.</p><p>Debatemos	que,	em	se	tratando	de	banco	de	dados,	dois	são	os	principais</p><p>modelos	—	o	modelo	E-R	e	o	modelo	orientado	a	objetos	—	e	que,	enquanto</p><p>o	modelo	entidade-relacionamento	é	utilizado	largamente,	o	orientado	a</p><p>objetos	ainda	é	muito	incipiente	tecnologicamente,	mas	possui	um	grande</p><p>campo	 de	 expansão	 pela	 frente;	 basta	 definir	 ainda	 algumas	 questões,</p><p>principalmente	as	relacionadas	à	padronização.</p><p>Tecnologias front-end	são	as	ferramentas	de	modelagem	e	as	linguagens</p><p>de	programação	orientada	a	objetos.</p><p>Para	 uma	 linguagem	 ser	 considerada	 orientada	 a	 objetos,	 ela	 deve</p><p>seguir	 algumas	predefinições,	 que	 são	possibilitar:	 o	 encapsulamento	de</p><p>dados,	a	abstração	de	dados,	a	coesão	dinâmica	e	a	herança.	Linguagens</p><p>puramente	orientadas	a	objetos,	como	vimos	em	Lee	e	Tapfenhart	(2001),</p><p>não	tiveram	grande	apelo	no	desenvolvimento	de	sistemas	comerciais	e,</p><p>para	 tal,	 foram	estendidas	para	utilizar	 técnicas	não	orientadas	a	objeto</p><p>apenas quando apropriado.</p><p>As	linguagens	OO	mais	utilizadas	na	atualidade	são	Java	e	as	linguagens</p><p>da	 plataforma	 Microsoft	 .Net,	 em	 especial,	 a	 linguagem	 C#.	 Debatemos</p><p>que,	na	discussão	sobre	qual	das	duas	é	melhor,	 raramente	se	 levam	em</p><p>consideração	os	números.	 Como	mostra	 a	 pesquisa	do	 Instituto	Gartner</p><p>(DRIVER,	 2007),	 as	 discussões	 partem	 sempre	 para	 o	 lado	 passional	 e</p><p>acabam se baseando em interesses particulares.</p><p>A segunda frente desta unidade tratou do tema da passagem da fase de</p><p>análise	para	a	fase	de	projeto,	cujo	objetivo	central	é	refinar	o	modelo	de</p><p>67</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>domínio	produzido	na	análise	para	obter	o	modelo	de	projeto,	um	modelo</p><p>que	possa	ser	implementável.</p><p>A	 fase	 de	 projeto,	 ou	 design,	 começa	 a	 partir	 do	 momento	 em	 que</p><p>fechamos	 a	 primeira	 versão	 do	 modelo	 de	 classe	 de	 domínio;	 nesse</p><p>momento,	temos	a	transição	análise-projeto.</p><p>São	 três	 perspectivas	 do	 modelo	 de	 classes:	 modelo	 conceitual,</p><p>produzido	 na	 fase	 de	 análise;	 modelo	 de	 projeto,	 produzido	 na	 fase	 de</p><p>projeto;	 e	 modelo	 de	 implementação,	 que	 corresponde	 ao	 modelo	 de</p><p>projeto	construído	em	uma	determinada	linguagem.</p><p>A	diferença	entre	o	modelo	conceitual	e	o	de	projeto	está	na	adição,	no</p><p>modelo	de	projeto,	dos	tipos	de	dados,	assinatura	dos	métodos,	detalhamento</p><p>dos	atributos	e	métodos	e	inclusão	de	novos	objetos	inerentes	à	solução</p><p>técnica	com	o	objetivo	de	que	este	modelo	possa	ser	 implementável,	ou</p><p>seja,	construído.</p><p>Segundo	 Bezerra	 (2006),	 são	 três	 as	 atividades	 para	 a	 passagem	 da</p><p>análise	para	o	projeto:	detalhamento	dos	aspectos	dinâmicos	do	sistema,</p><p>refinamento	dos	aspectos	estáticos	e	estruturais	do	sistema	e	definição	de</p><p>outros	aspectos	da	solução.</p><p>Na	 fase	 de	 detalhamento	 dos	 aspectos	 dinâmicos	 do	 sistema	 nós</p><p>damos	ênfase	à	representação	da	troca	de	mensagens	entre	os	objetos	com</p><p>o	objetivo	de	resolver	um	determinado	problema.</p><p>No	 refinamento	 dos	 aspectos	 estáticos	 e	 estruturais,	 a	 ênfase</p><p>é	 dada	 a	 refinar	 o	 modelo	 conceitual	 de	 tal	 forma	 que	 esse	 novo</p><p>modelo	possa	ser	implementável	a	partir	da	adição	dos	tipos	de	dados,</p><p>assinatura	 dos	 métodos,	 detalhamento	 dos	 atributos	 e	 métodos	 e</p><p>inclusão	 de	 novos	 objetos,	 se	 necessário,	 e	 neste	 ponto	 vimos	 que</p><p>uma	classe	do	modelo	de	classes	de	domínio	pode	gerar	uma	ou	mais</p><p>classes	no	modelo	de	classes	de	projeto	e	vice-versa,	e	 isso	é	muito</p><p>importante ter em mente.</p><p>Por	último,	na	definição	de	outros	aspectos	da	solução,	demos	ênfase	a:</p><p>arquitetura,	componentização,	distribuição	dos	componentes	nos	recursos</p><p>de hardware	e	mapeamento	dos	objetos	em	um	SGBD.</p><p>Cada	fase	possui	a	sua	sequência	de	atividades,	no	entanto	é	importante</p><p>que	tenhamos	em	mente	que	sempre	podemos,	e	devemos,	refinar	e	corrigir</p><p>modelos	produzidos	nas	fases	anteriores	quando	necessário.</p><p>68</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Exercícios</p><p>Questão 1. A UML (Unified Modeling Language),	na	definição	de	Booch	et al. (2006, p. 13), “é</p><p>uma	 linguagem-padrão	 para	 elaboração	 da	 estrutura	 de	 projetos	 de	 software [...] adequada para a</p><p>modelagem	de	sistemas”.	Com	relação	a	UML,	analise	as	duas	afirmativas	apresentadas	a	seguir:</p><p>Existem	inúmeras	ferramentas	no	mercado	que	se	utilizam	da	UML	para	a	geração	de	diagramas.	A</p><p>própria	UML	em	si	pode	ser	considerada	uma	plataforma	ou	uma	ferramenta	de	modelagem.</p><p>Porque</p><p>A	UML	não	é	uma	 linguagem	de	programação,	muito	embora	 seja	possível	a	geração	de	código</p><p>a	partir	de	alguns	diagramas,	o	diagrama	de	classes	principalmente,	assim	como	o	inverso,	ou	seja,	a</p><p>geração	de	diagramas	a	partir	de	código	fonte.</p><p>Acerca	dessas	afirmativas,	assinale	a	opção	correta:</p><p>A)	 As	 duas	 afirmativas	 são	 proposições	 verdadeiras	 e	 a	 segunda	 é	 uma	 justificativa	 correta	 da</p><p>primeira.</p><p>B)	As	duas	afirmativas	são	proposições	verdadeiras	e	a	segunda	não	é	uma	justificativa	correta	da</p><p>primeira.</p><p>C)	A	primeira	afirmativa	é	uma	proposição	verdadeira	e	a	segunda	é	uma	proposição	falsa.</p><p>D)	A	primeira	afirmativa	é	uma	proposição	falsa	e	a	segunda	é	uma	proposição	verdadeira.</p><p>E)	As	duas	afirmativas	são	proposições	falsas.</p><p>Resposta	correta:	alternativa	D.</p><p>Análise das alternativas</p><p>Justificativa	 geral:	 a	 primeira	 afirmativa	 é	 uma	 proposição	 falsa	 e	 a	 segunda	 é	 uma	 proposição</p><p>verdadeira.</p><p>A	versão	correta	da	primeira	afirmativa	é:</p><p>Existem</p><p>inúmeras	ferramentas	no	mercado	que	se	utilizam	da	UML	para	a	geração	de	diagramas,	mas</p><p>a	UML	em	si	não	pode	ser	considerada	uma	plataforma	ou	uma	ferramenta	de	modelagem	tampouco</p><p>um software.</p><p>69</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Como	apresentado	no	 livro-texto,	a	confusão	nesse	ponto	se	dá	pela	 falsa	sensação	de	que	não</p><p>conseguimos	 trabalhar	 com	 UML	 e	 desenvolver	 diagramas	 sem	 que	 tenhamos	 uma	 ferramenta	 de</p><p>modelagem.</p><p>Questão 2. Com	 relação	 à	 modelagem	 de	 Sistemas	 Gerenciadores	 de	 Banco	 de	 Dados,	 alguns</p><p>pontos	 do	 modelo	 orientado	 a	 objetos	 marcam	 sua	 diferença	 conceitual	 para	 o	 modelo	 Entidade-</p><p>Relacionamento.</p><p>Com	base	nas	diferenças	do	modelo	orientado	a	objetos	avalie	as	afirmativas	a	seguir:</p><p>I	–	Cada	objeto	possui	um	conjunto	de	códigos	que	operam	sobre	este	objeto,	chamado	de	método.</p><p>II	–	Cada	objeto	possui	uma	identidade	única	independente	dos	valores	contidos	em	seus	atributos,</p><p>ou	 seja,	mesmo	que	um	objeto	possua	os	mesmos	valores	dos	atributos	de	outro	objeto	no	mesmo</p><p>banco de dados, estes possuem identidades diferentes.</p><p>III	–	A	presença	de	atributos.</p><p>IV	–	Adoção	de	mecanismos	de	relacionamento:	composição,	agregação	e	herança.</p><p>É	correto	apenas	o	que	apenas	se	afirma	em:</p><p>A)	I	e	II.</p><p>B)	II	e	IV.</p><p>C)	I,	II,	III	e	IV.</p><p>D)	I,	II,	e	IV.</p><p>E)	I	e	III.</p><p>Resolução desta questão na plataforma.</p><p>70</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Unidade III</p><p>5 PROJETOS DE DADOS E CLASSES E PROJETO ARQUITETURAL</p><p>5.1 Projeto de dados e classes</p><p>Como vimos na Unidade I, a fase de projetos é organizada em quatro fases: projeto de dados, projeto</p><p>arquitetural, projeto de interfaces e projeto de componentes.</p><p>Lembrete</p><p>A subdivisão das atividades na fase de projeto é delimitada pelos</p><p>artefatos que produzem.</p><p>Na Unidade II, tratamos do processo da passagem da fase de análise para a fase de projetos, ou seja,</p><p>entramos efetivamente na fase de projetos, na atividade de projeto de dados e classes, com a produção</p><p>do modelo de classes de projeto, realizado a partir do refinamento do diagrama de classes do domínio.</p><p>A partir de agora, trataremos única e exclusivamente das tarefas técnicas de projeto, tendo como</p><p>base o modelo de classes de projeto e dos aspectos dinâmicos do projeto de objetos mapeados até aqui.</p><p>Segundo Pressman (2006, p. 208), a fase de projetos de dados tem como objetivo a geração do</p><p>modelo de dados e a transformação de classes e objetos conceituais em classes e objetos equivalentes</p><p>em projeto.</p><p>Até este momento atingimos a parte de transformação de classes e objetos conceituais em classes e</p><p>objetos equivalentes em projeto; entraremos, agora, na modelagem de dados.</p><p>5.1.1 Introdução ao projeto de dados</p><p>O projeto de dados, ou modelagem de dados, tem como objetivo definir uma estrutura de informações</p><p>necessárias para implementar o sistema de software (PRESSMAN, 2006).</p><p>Em linhas gerais, devemos montar uma estrutura para armazenar, atualizar e recuperar as informações</p><p>do sistema.</p><p>Nesta fase, como estamos tratando de aspectos de construção do projeto, devemos determinar a</p><p>organização, métodos de acesso, associações e alternativas de processamento dessas informações.</p><p>71</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Como vimos, boa parte dessas atividades é feita pelo SGBD, que é o responsável por prover os</p><p>mecanismos de acesso, gerenciamento e processamento das informações em um repositório de dados.</p><p>Todavia, fica a cargo do projeto a adoção de um SGBD que satisfaça as necessidades do sistema de</p><p>software, e faz parte das atribuições técnicas do arquiteto o conhecimento das tecnologias disponíveis</p><p>a serem utilizadas.</p><p>Nesta fase daremos ênfase à organização das informações e em como representar um dicionário de</p><p>dados que dê suporte à resolução do problema pelo sistema de software.</p><p>Projetar um banco de dados também não é uma tarefa que pode ser realizada sem organização.</p><p>O processo de projeto de banco de dados pode ser subdividido em três fases: projeto conceitual,</p><p>projeto lógico e projeto físico, como mostra a figura a seguir (ELMASRI; NAVATHE, 2011).</p><p>Projeto conceitual</p><p>Modelo de dados de alto nível</p><p>Esquema interno do SGBD</p><p>Requisitos de dados</p><p>Análise de</p><p>requisitos</p><p>Modelo de dados lógicos de um SGBD específico</p><p>Projeto físico</p><p>SGBD</p><p>Projeto lógico</p><p>(mapeamento do modelo de dados)</p><p>Figura 19 – Projeto de banco de dados</p><p>•	 Projeto	conceitual:	tem	como	objetivo	produzir	um	modelo	de	alto	nível,	ou	seja,	sem	detalhes</p><p>específicos de um SGBD, que represente os requisitos de dados. Esses requisitos expressam tudo</p><p>aquilo que deverá ser armazenado pelo sistema, e o modelo de alto nível pode ser utilizado como</p><p>instrumento de validação com a própria área usuária.</p><p>•	 Projeto	lógico:	essa	fase	do	projeto	utiliza	como	base	o	modelo	produzido	no	projeto	conceitual</p><p>e monta o modelo de dados de implementação, que contempla detalhes que possam tornar esse</p><p>modelo implementável em um SGBD específico.</p><p>72</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>•	 Projeto	 físico:	 é	 a	 implementação	do	modelo	 lógico	 em	uma	 linguagem	de	programação	que</p><p>possa fazer a transação do modelo lógico para o esquema interno do SGBD. É a concretização do</p><p>projeto de dados.</p><p>Atualmente, como já mencionamos, o modelo de dados relacional é um dos modelos mais utilizados</p><p>quando falamos em paradigma de projetos de banco de dados.</p><p>Saiba mais</p><p>Aprofunde seus conhecimentos sobre outros modelos de banco de</p><p>dados, como o modelo orientado a objetos, em:</p><p>ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São</p><p>Paulo: Addison-Wesley, 2011.</p><p>SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de</p><p>dados. 5. ed. Rio de Janeiro. Campus, 2006.</p><p>5.1.2 Introdução a banco de dados relacionais</p><p>O modelo entidade relacional enxerga os dados do mundo real como o conjunto: entidade, atributos</p><p>e relacionamento. Cada entidade, ou um conjunto de entidades, gera uma tabela, seus atributos ou</p><p>características são representados por colunas desta tabela e cada linha desta tabela representa uma</p><p>instância dessa entidade.</p><p>A figura a seguir mostra um exemplo de um modelo conceitual, de alto nível, produzido na fase conceitual</p><p>do projeto de banco de dados, e o quadro na sequência explica o significado de cada um desses elementos.</p><p>Suponhamos que o cenário de negócio a ser modelado seja a inscrição de alunos para cursar</p><p>disciplinas. Nesse caso fictício, um aluno pode não estar inscrito em nenhuma disciplina ou pode estar</p><p>inscrito em várias (sem limite preestabelecido), enquanto uma disciplina pode não ter nenhum aluno</p><p>inscrito ou possuir no máximo quarenta inscrições.</p><p>Matrícula Nome NomeTurma</p><p>Aluno</p><p>Cursa</p><p>(0, N) (0, 40)</p><p>Disciplina</p><p>Código</p><p>A A</p><p>B</p><p>D</p><p>C C</p><p>D</p><p>Figura 20 – Modelo Conceitual E-R</p><p>73</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Quadro 7 – Elementos do modelo conceitual E-R</p><p>Letra Descrição</p><p>A Entidades: representação de algo do mundo real.</p><p>B</p><p>Relacionamento: indicação do relacionamento entre duas entidades. No</p><p>exemplo, a relação entre “Aluno” e “Disciplina” é “Cursa”. A leitura que podemos</p><p>fazer deste modelo é: Aluno(s) cursa(m) Disciplina(s) e Disciplina(s) é(são)</p><p>cursada(s) por Aluno(s).</p><p>C</p><p>Atributos: conjunto de características de uma entidade. No exemplo, podemos</p><p>fazer as seguintes leituras:</p><p>- Aluno possui: Matrícula, Nome e Turma;</p><p>- Disciplina possui: Código e Nome;</p><p>Obs: note que os atributos “Matricula” em “Aluno” e “Codigo” em “Disciplina”</p><p>estão sublinhados.</p><p>Esses atributos são “Chaves Primárias” de suas entidades;</p><p>isso quer dizer</p><p>que esses campos são identificadores únicos de uma entidade, ou seja, um</p><p>aluno nunca poderá possuir uma matrícula igual ao outro e um código de</p><p>disciplina nunca poderá ser repetido.</p><p>Os conceitos de chave primária e identificadores únicos, em banco de dados,</p><p>garantem a identidade e a integridade referencial.</p><p>D</p><p>Multiplicidade: denota a proporção, ou a quantificação, do relacionamento</p><p>entre duas entidades. No caso do exemplo, fazemos as seguintes leituras:</p><p>- Um aluno cursa no mínimo zero disciplina e no máximo N (sem número</p><p>preciso) disciplina(s).</p><p>- Uma disciplina é cursada por no mínimo zero aluno e no máximo quarenta.</p><p>Existem as seguintes representações de multiplicidade:</p><p>(0,1): lê-se zero para um;</p><p>(1,1): lê-se um para um;</p><p>(0,N): lê-se zero para N;</p><p>(1,N): lê-se um para N.</p><p>Note que no exemplo da figura anterior os atributos das entidades não possuem tipos de dados;</p><p>não sabemos, por exemplo, se o código da disciplina é um número ou um texto, e essas informações são</p><p>importantes para a conversão dessas entidades em tabelas do SGBD.</p><p>Para isso, seguindo o processo de projeto de banco de dados, precisamos adentrar a fase de projeto</p><p>lógico, para o refinamento do modelo conceitual de tal forma que geremos um modelo lógico mais</p><p>próximo do que será implementado no SGBD.</p><p>No nosso exemplo de disciplina/aluno, suponhamos que esse modelo gere tabelas que, quando</p><p>preenchidas, produzam algo como:</p><p>74</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Figura 21 – Exemplo de tabelas E-R</p><p>Nesse caso, a partir da figura anterior, podemos pensar, por exemplo, que o código da disciplina é</p><p>um texto e que a matrícula do aluno é um número. Mas isso ainda não é suficiente, isso são apenas</p><p>suposições. Além do mais, a partir desse modelo de tabela simulado, não conseguimos saber quais alunos</p><p>estão matriculados em uma determinada disciplina, nem em quantas disciplinas um determinado aluno</p><p>está matriculado, como indicado pelo modelo conceitual.</p><p>Faz-se necessário o desenvolvimento de um modelo lógico, como mostram o exemplo da figura</p><p>seguinte e o quadro explicativo na sequência.</p><p>Figura 22 – Exemplo de modelo lógico (Diagrama E-R)</p><p>Neste caso, podemos observar a criação de uma terceira entidade, que implementa o relacionamento</p><p>proposto pelo modelo conceitual. Ainda é possível notarmos, nessa entidade, o uso do conceito de chave</p><p>estrangeira (ou foreign key/FK).</p><p>Chave estrangeira pode ser considerada como uma referência à chave primária de outra tabela em</p><p>uma relação entre duas entidades. No caso do nosso exemplo, as chaves primárias “codigo” e “matricula”</p><p>tornam-se referências na entidade “aluno_disciplina”, uma vez que esses atributos são identificadores</p><p>de suas respectivas entidades.</p><p>75</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Podemos notar também a simbologia da representação da cardinalidade. Enquanto no modelo</p><p>conceitual tínhamos a notação da cardinalidade explícita, no modelo lógico temos a representação em</p><p>simbologia.</p><p>A próxima figura mostra a simbologia para representação de cardinalidade e seus respectivos</p><p>significados.</p><p>Cardinalidade Representação</p><p>(0,1)</p><p>(1,1)</p><p>(0,N)</p><p>(1,N)</p><p>Figura 23 – Representação de cardinalidade ER</p><p>Assim, esse modelo lógico, quando simulado em uma estrutura de tabelas e com informações</p><p>fictícias, produz o resultado exibido pela figura a seguir:</p><p>Figura 24 – Exemplos de tabelas E-R</p><p>76</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>A partir do exemplo desta última figura, podemos visualizar quais alunos cursam uma determinada</p><p>disciplina e quais disciplinas um aluno cursa. Todavia, ainda não conseguimos saber os tipos de dados</p><p>dos atributos.</p><p>Precisamos de um modelo mais próximo do SGBD, que é o que o modelo físico se presta a fazer. Um</p><p>exemplo de como seria o modelo físico, implementado a partir da linguagem SQL, utilizando o SGBD</p><p>MySQL, segue na próxima figura:</p><p>Figura 25 – Exemplo de modelo físico E-R</p><p>Se executarmos o script descrito pela figura anterior em um SGBD MySQL, serão criadas três tabelas,</p><p>com seus respectivos atributos, tipos de dados, chaves primárias e chaves estrangeiras.</p><p>Retomando a orientação a objetos, os dados de uma classe têm de ser, muitas vezes, persistidos.</p><p>Persistir um dado é colocá-lo em um meio de guarda permanente, em geral um banco de dados.</p><p>77</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>5.1.3 Bancos de dados relacionais versus orientação a objetos</p><p>Pode-se notar que o modelo relacional e o modelo orientado a objetos possuem certas diferenças,</p><p>por exemplo, no modelo relacional, não temos o armazenamento dos métodos que poderiam agir sobre</p><p>uma determinada classe.</p><p>Em contrapartida, esses modelos possuem semelhanças:</p><p>•	 Assim	como	na	orientação	a	objetos,	uma	entidade	possui	atributos.</p><p>•	 Assim	como	na	orientação	a	objetos,	uma	entidade	possui	uma	identidade,	que	pode	ser	obtida	a</p><p>partir de um conjunto de valores de seus atributos. Podemos dizer então que cada linha de uma</p><p>tabela é uma instância de uma entidade, ou um objeto.</p><p>•	 Assim	como	na	orientação	a	objetos,	as	entidades	se	relacionam.</p><p>É exatamente aqui que está um dos principais problemas na relação entre paradigma orientado a</p><p>objetos e modelo relacional: como representar algumas características da orientação a objetos, herança,</p><p>por exemplo, já que não existe herança em modelos relacionais?</p><p>Uma possível solução para o problema está no banco de dados orientado a objetos. Todavia, como</p><p>vimos, o modelo orientado a objetos ainda é muito incipiente.</p><p>A saída viável é fazer um “mapeamento” entre as classes do modelo orientado a objetos e as entidades</p><p>do modelo relacional. Para fazer a persistência dos dados é necessário mapear as classes cujos objetos</p><p>se deseja persistir em tabelas.</p><p>Quando definimos o modelo de classes de projetos e atribuímos as responsabilidades para cada</p><p>classe dentro do sistema de software, modelamos classes transientes ou que não tenham necessidade</p><p>de persistência, como aquelas que só contêm métodos, classes do tipo controle.</p><p>Lembrete</p><p>Temos três tipos de classes, quando analisamos pela questão</p><p>responsabilidade, no paradigma orientado a objetos: entidade (entity),</p><p>controle (control) e fronteira (boundary).</p><p>Olhando por esse aspecto, classes de fronteira (boundary) geralmente são transientes, bem como as</p><p>classes de controle (control), logo não precisam ser persistidas, pois são compostas, em sua maioria, de</p><p>métodos, e os poucos atributos que possuem não necessitam ser persistidos.</p><p>Outro ponto importante: neste mapeamento, é necessário mapear se todos os atributos serão</p><p>persistidos ou apenas uma parte, pois podem existir atributos em uma classe que não necessariamente</p><p>precisem ser persistidos, que são usados somente no contexto da aplicação.</p><p>78</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Existem algumas formas de se persistir uma classe em uma ou mais tabelas.</p><p>A situação mais simples é quando uma classe é persistida diretamente em uma tabela; neste caso,</p><p>o único trabalho é verificar quais atributos serão persistidos e eventualmente fazer uma adaptação de</p><p>chave primária, criando ou alterando uma existente.</p><p>A segunda situação é quando temos uma composição de classes que, no caso do modelo</p><p>E-R, denote uma associação do tipo “um para muitos”. Nesse caso, é necessário adicionar uma</p><p>chave estrangeira na extremidade “muitos” para referenciar a chave primária da tabela da outra</p><p>extremidade.</p><p>A terceira situação é quando temos uma composição de classes que, no caso do modelo E-R, denote</p><p>uma associação do tipo “muitos para muitos”. Nesse</p><p>relacionais versus orientação a objetos ..................................................... 77</p><p>5.2 Projeto arquitetural ............................................................................................................................. 81</p><p>5.2.1 Qual o papel da arquitetura? ............................................................................................................. 81</p><p>5.2.2 O que é arquitetura de software? .................................................................................................... 82</p><p>5.2.3 A importância da arquitetura de software ................................................................................... 83</p><p>5.2.4 Processo de arquitetura de software .............................................................................................. 84</p><p>5.2.5 Processo de arquitetura de software em aspectos humanos ............................................... 87</p><p>6 VISÕES DA ARQUITETURA DE SOFTwARE ............................................................................................. 88</p><p>6.1 Visão estática ......................................................................................................................................... 88</p><p>6.1.1 Utilização de padrões na arquitetura de software .................................................................... 89</p><p>6.1.2 Estilo arquitetural ................................................................................................................................... 90</p><p>6.1.3 Estruturação de sistemas em subsistemas e camadas ............................................................ 92</p><p>6.1.4 Introdução a padrões de projeto (design patterns) .................................................................. 96</p><p>6.2 Visão dinâmica ....................................................................................................................................101</p><p>6.2.1 Definindo responsabilidades ............................................................................................................102</p><p>6.2.2 Refinando o diagrama de sequência ............................................................................................103</p><p>6.3 Documentação de arquitetura ......................................................................................................104</p><p>Unidade IV</p><p>7 REFINANDO A MODELAGEM DE ASPECTOS DINÂMICOS DO SOFTwARE ...............................110</p><p>7.1 Diagrama de comunicação .............................................................................................................110</p><p>7.2 Diagrama de máquina de estado .................................................................................................114</p><p>8 PROJETO DE INTERFACES E PROJETO DE COMPONENTES ............................................................121</p><p>8.1 Projeto de interfaces .........................................................................................................................121</p><p>8.1.1 Especificando as interfaces dos objetos ..................................................................................... 122</p><p>8.1.2 Diagrama de pacotes .......................................................................................................................... 123</p><p>8.1.3 Introdução ao projeto de interfaces com o usuário .............................................................. 129</p><p>8.2 Projeto de componentes .................................................................................................................130</p><p>8.2.1 Introdução à componentização e ao reúso de software ..................................................... 130</p><p>8.2.2 Definindo as interfaces externas ................................................................................................... 132</p><p>8.2.3 Diagrama de componentes .............................................................................................................. 133</p><p>8.2.4 Diagrama de distribuição ................................................................................................................. 135</p><p>7</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>APreSentAçãO</p><p>A disciplina Projeto de Sistemas Orientado a Objetos tem como objetivo apresentar ao aluno as boas</p><p>práticas para transformar as necessidades das organizações, inseridas em um mercado cada vez mais</p><p>competitivo, em um projeto de software eficiente, com qualidade de desenvolvimento e, principalmente, que</p><p>possibilite vantagem competitiva à organização, utilizando para isso o paradigma da orientação a objetos.</p><p>Para atingir este objetivo a disciplina começa contextualizando para o aluno os problemas que o</p><p>projeto software enquanto atividade do ciclo de vida do software se propõe a resolver.</p><p>Com o aluno integrado na temática, a disciplina apresenta e discute a importância de as atividades</p><p>de projeto serem executadas de forma organizada dentro de um projeto de software, apresentando</p><p>as principais metodologias e técnicas empregadas no processo de transformação das necessidades da</p><p>organização em sistema de software.</p><p>Conceitos básicos e motivações postos, debate-se a arquitetura de software como fase fundamental</p><p>dentro de um projeto de desenvolvimento, explanando a importância dos modelos e mostrando as</p><p>principais técnicas para modelagem, documentação e padrões utilizados para definição da arquitetura</p><p>de um sistema de software.</p><p>Dentro de todo esse contexto, a disciplina apresenta as tecnologias que dão suporte ao projeto</p><p>orientado a objetos e os diagramas da UML (Unified Modeling Language) como uma ferramenta para</p><p>representação e modelagem de um sistema de software, utilizando-os como ferramenta de apoio em</p><p>todo o processo.</p><p>IntrOduçãO</p><p>Desde que o software se estabeleceu como uma ferramenta importante na estratégia competitiva</p><p>das grandes empresas, a indústria de desenvolvimento vem passando por transformações para atender</p><p>as necessidades cada vez maiores deste mercado.</p><p>O desafio lançado não está mais no simples fato de se desenvolver uma série de linhas de código</p><p>que, agrupadas, compõem um sistema de software, mas sim em desenvolver este software como um</p><p>produto, como uma ferramenta de estratégia competitiva que atenda a uma série de exigências e</p><p>determinados padrões de qualidade.</p><p>O velho paradigma de que “software bom é aquele que funciona” começa a ser quebrado por esses</p><p>padrões de qualidade. Atualmente, o mínimo que se espera de um software é que ele funcione; é o</p><p>mínimo que se exige para que tanto a organização que utiliza o sistema quanto aquela que o desenvolveu</p><p>se mantenham em um mercado cada vez mais competitivo.</p><p>Se o software deve ser enxergado como uma ferramenta de estratégia competitiva em uma grande</p><p>corporação, parece-nos razoável que um projeto não deva tomar um tempo excessivo, afinal de contas,</p><p>em um mercado cada vez mais competitivo, tem a vantagem aquele que larga na frente.</p><p>8</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Seguindo a mesma linha de raciocínio, espera-se que um projeto não tenha custos exorbitantes,</p><p>o que pode inclusive torná-lo inviável. Em casos de projetos malsucedidos, o custo de um processo</p><p>de negócio realizado de forma não automatizada pode ser mais vantajoso que automatizá-lo. Logo,</p><p>podemos notar que o software deve ter boa relação custo-benefício.</p><p>Idealmente, um projeto deve ser executado em um tempo razoável e com um custo viável. Como se</p><p>isso não bastasse, um sistema de software competitivo deve atingir certo nível de qualidade.</p><p>Palavras como manutenibilidade, desempenho, escalabilidade, disponibilidade, dentre outras,</p><p>permeiam, cada vez mais, o universo da engenharia de software e demonstram o nível de qualidade que</p><p>se espera de um sistema de software.</p><p>O nível de qualidade de um sistema de software pode ser traduzido não só pelo nível de atingimento</p><p>de automatização das necessidades de negócio, mapeados na engenharia de requisitos, mas</p><p>caso, é necessário criar uma tabela intermediária</p><p>contendo duas chaves estrangeiras, cada uma relacionada à chave primária de cada classe do</p><p>relacionamento.</p><p>A quarta e última situação é o grande problema do mapeamento E-R/orientado a objetos: como</p><p>mapear herança? Como mapear uma relação?</p><p>Figura 26 – Exemplo de relação de herança a ser mapeada no modelo E-R</p><p>Temos três possíveis soluções.</p><p>Solução A: criar uma entidade única contendo todas as informações, conforme mostra a figura a</p><p>seguir. Neste caso, teríamos uma desvantagem, pois alguns campos ficariam vazios quando fôssemos</p><p>persistir um professor ou um aluno, e isso é péssimo para o desempenho do banco de dados e para o</p><p>79</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>algoritmo tratamento no sistema de software. Como resultado dessa solução, com os dados preenchidos</p><p>na tabela, teríamos o que segue na figura:</p><p>Figura 27 – Resultado da Solução A</p><p>Solução B: criar duas entidades, uma para professor e outra para aluno, como mostra a figura a</p><p>seguir. Eliminaríamos o problema dos campos vazios, todavia teríamos os mesmos atributos mapeados</p><p>em entidades diferentes, o que também não é produtivo. Como resultado dessa solução, com os dados</p><p>preenchidos nas tabelas, teríamos o que segue nas figuras:</p><p>Figura 28 – Resultado da Solução B</p><p>Solução C: criar três entidades, “aluno”, “professor” e uma terceira entidade conceitual “pessoa”.</p><p>Eliminaríamos o problema dos campos vazios, não teríamos os mesmos atributos mapeados em entidades</p><p>diferentes, todavia teríamos a necessidade da criação de um uma terceira entidade, apenas conceitual, e</p><p>teríamos um custo para manter esse modelo. Como resultado dessa solução, com os dados preenchidos</p><p>nas tabelas, teríamos o que segue nas figuras:</p><p>80</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Figura 29 – Resultado da Solução C</p><p>Dentre as três situações, a que fere menos os princípios da normalização de banco de dados é</p><p>a situação C; de qualquer forma, temos de ter em mente que não existe uma adaptação natural do</p><p>modelo E-R para o modelo OO.</p><p>Observação</p><p>Normalização é o nome que se dá ao processo de organizar e dividir</p><p>as tabelas da forma mais eficiente possível, diminuindo a redundância e</p><p>permitindo a evolução do BD com o mínimo de efeitos colaterais.</p><p>Atualmente existem alguns frameworks, ou bibliotecas prontas, chamados frameworks, de</p><p>persistência, por exemplo, o NHibernate, para aplicações baseadas no Microsoft .Net, e o Hibernate,</p><p>similar, utilizado para soluções desenvolvidas utilizando a plataforma Java.</p><p>O objetivo desses componentes é justamente fazer o mapeamento, de forma automática, do</p><p>modelo orientado a objetos para o E-R e vice-versa, além de abstrair para o desenvolvedor todo o</p><p>81</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>gerenciamento dessas informações no SGDB, ou seja, o próprio framework disponibiliza funções prontas</p><p>para criação, atualização e recuperação das informações do BD para o modelo orientado a objetos, sem</p><p>que o desenvolvedor necessite desenvolver essas funcionalidades.</p><p>Observação</p><p>Atualmente, a interface entre uma aplicação e as funções para</p><p>criação, atualização e recuperação das informações do BD se dá a partir</p><p>do desenvolvimento de consultas baseadas na linguagem SQL, e essas</p><p>consultas são desenvolvidas pela equipe de construção.</p><p>A única e principal ressalva a ser feita na adoção desses mecanismos é que, muito embora sejam</p><p>facilitadores na produtividade do desenvolvimento, eles passam a não ter um bom desempenho, uma</p><p>vez que uma das partes do modelo não está benfeita.</p><p>Normalmente, quando estamos tratando de sistemas legados, ou que já existam há algum tempo,</p><p>é comum que nos deparemos com modelos E-R, ou até mesmo modelos de classes, desenvolvidos sem</p><p>utilizar as melhores práticas.</p><p>Nesses casos, não é recomendável a utilização destes frameworks. Em muitos casos, na fase de</p><p>projeto, tecnologia alguma substitui a capacidade analítica da equipe de projeto.</p><p>5.2 Projeto arquitetural</p><p>Neste subtópico avançaremos para a fase de projeto arquitetural, que é a fase seguinte à de projeto</p><p>de dados e classes que debatemos no subtópico anterior.</p><p>5.2.1 Qual o papel da arquitetura?</p><p>Na engenharia civil, arquitetura é a arte de projetar e construir prédios, edifícios ou outras estruturas,</p><p>a constituição de um edifício ou a contextura de um todo (MICHAELIS, 1998).</p><p>Analogamente à arquitetura na engenharia civil, a arquitetura desempenha papel importante</p><p>também na engenharia de software.</p><p>Na engenharia de software, o papel da arquitetura é bem semelhante ao da arquitetura na engenharia</p><p>civil, ou seja, projetar estruturas, a constituição de um software ou a contextura de um todo, assim</p><p>como na arquitetura da engenharia civil.</p><p>A figura a seguir mostra exatamente onde a arquitetura se encontra dentro do contexto do ciclo de</p><p>vida de um projeto de software.</p><p>82</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Implementação</p><p>Necessidade</p><p>Arquitetura</p><p>Figura 30 – Disposição da arquitetura dentro de um projeto de software</p><p>Arquitetura de software é o nome dado à disciplina fundamental da fase de projeto arquitetural.</p><p>5.2.2 O que é arquitetura de software?</p><p>Algumas das definições clássicas de arquitetura de software são:</p><p>•	 Arquitetura	de	software é uma representação do sistema que auxilia na compreensão de como ele</p><p>irá se comportar (SEI, 2015a).</p><p>•	 Arquitetura	 de	 software é uma descrição de como um sistema de software é organizado</p><p>(SOMMERVILLE, 2010).</p><p>•	 Arquitetura	 é	 a	 organização	 fundamental	 de	 um	 sistema	 incorporada	 em	 seus	 componentes,</p><p>seus relacionamentos com o ambiente, e nos princípios que conduzem seu projeto, construção e</p><p>evolução (ISO, 2011b).</p><p>•	 Arquitetura	de	software pode ser definida como uma representação, em alto nível de abstração,</p><p>dos componentes de um sistema de software, suas propriedades externamente visíveis, e como</p><p>estes interagem com o objetivo de resolver as necessidades, ou problema de um cenário de negócio</p><p>(BASS; CLEMENTS; KAZMAN, 2010).</p><p>Observação</p><p>A norma ISO/IEC/IEEE 42010 (2011b) tem como objetivo padronizar a</p><p>prática da arquitetura definindo termo, apresentando uma base conceitual</p><p>para expressar, comunicar e rever arquiteturas e especificações de requisitos</p><p>que se aplicam às descrições de arquitetura, frameworks arquiteturais e</p><p>linguagens de descrição de arquitetura. Esta norma substitui a norma ISO</p><p>1471 de 2000.</p><p>Todas as definições de arquitetura de software corroboram um conceito único: o de projeto de</p><p>software.</p><p>83</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Está claro que a arquitetura de um software não é o software em si, mas sim a representação, o</p><p>modelo, a organização do software que será efetivamente construído.</p><p>Mais importante do que pensar em componentes de um sistema de software e como estes se</p><p>comunicam é pensar na natureza desses componentes, quais são suas responsabilidades, qual é o</p><p>significado de suas conexões e qual o significado da forma como estes componentes estão distribuídos</p><p>no modelo (BASS; CLEMENTS; KAZMAN, 2010).</p><p>O tema Arquitetura de Software é bem amplo. O livro de Bass, Clements e Kazman (2010), que é uma</p><p>das principais referências no tema, entende que pensar na natureza dos componentes é uma forma</p><p>diferente de se pensar em arquitetura de software.</p><p>Os autores ainda defendem que essa abordagem deve ter ênfase nos requisitos não funcionais, ou</p><p>atributos de qualidade, do problema a ser resolvido.</p><p>Esta ênfase nos atributos de qualidade dá-se pela maior dependência destes em</p><p>relação à estrutura</p><p>do software, uma vez que as funcionalidades, ou requisitos funcionais, podem ser implementadas em</p><p>um número maior de alternativas, sendo assim menos dependentes das decisões arquiteturais (BASS;</p><p>CLEMENTS; KAZMAN, 2010).</p><p>5.2.3 A importância da arquitetura de software</p><p>A importância fundamental da arquitetura de um software é a mesma importância que a arquitetura</p><p>tem na construção de uma casa: a arquitetura, ou o projeto arquitetural, representado por uma planta,</p><p>por exemplo, é o principal guia para a construção.</p><p>Assim como a arquitetura na engenharia civil, a arquitetura de software produz modelos e organiza</p><p>a estrutura de um software de tal forma que sirva como o principal guia para a construção.</p><p>Segundo o SEI (2015a), a arquitetura de um sistema de software serve como modelo tanto para o</p><p>projeto quanto para a construção, facilitando inclusive a divisão das tarefas a serem realizadas pela</p><p>equipe de projeto e de construção.</p><p>Além do mais, a arquitetura é o principal meio para o atingimento de qualidade de um sistema</p><p>como: desempenho, manutenibilidade e segurança. Nenhum índice de qualidade pode ser alcançado</p><p>sem uma visão arquitetural unificada (SEI, 2015a).</p><p>Observação</p><p>Note que, assim como Bass, Clements e Kazman (2010), o SEI (2015a)</p><p>bate na tecla de que a arquitetura de software está intimamente ligada aos</p><p>atributos de qualidade, ou requisitos não funcionais, que podem ser vistos,</p><p>por exemplo, na norma ISO 25010 (ISO, 2011a).</p><p>84</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Bass, Clements e Kazman (2010) pontuam a importância da arquitetura de software:</p><p>•	 Facilita	a	comunicação	entre	os	envolvidos	no	projeto.</p><p>•	 Representa,	em	escala	menor	e	compreensível,	a	forma	pela	qual	os	componentes	de	um	sistema</p><p>são estruturados e interagem.</p><p>•	 Modela	e	coloca	em	evidência	as	decisões	de	projeto	como	fator	fundamental	para	o	sucesso	do</p><p>sistema de software.</p><p>Alguns outros benefícios de uma arquitetura bem-definida para um sistema de software:</p><p>•	 Facilita	a	evolução	do	software.</p><p>•	 Facilita	 o	 reúso	 de	 componentes,	 logo	 promove	 maior	 produtividade	 na	 construção	 e	 na</p><p>manutenção, pois também facilita a manutenção.</p><p>•	 Promove	a	diminuição	do	espaço	entre	as	fases	de	análise	e	construção	e,	por	consequência,	a</p><p>diminuição do retrabalho na construção.</p><p>•	 Auxilia	a	gestão	do	projeto	quanto	à	estimativa	de	tempo,	ao	custo	e	à	complexidade	do	projeto.</p><p>•	 Promove	mitigação	e	diminuição	de	riscos.</p><p>5.2.4 Processo de arquitetura de software</p><p>Segundo Albin (2003), a participação de arquitetura de software pode ser dividida em cinco fases, e</p><p>deve ser iniciada antes mesmo da fase de projetos do ciclo de vida da engenharia de software:</p><p>Fases do ciclo de vida da engenharia de software Fases da arquiteura</p><p>Análise de requisitos Pré-projeto</p><p>Projeto</p><p>Análise de domínio</p><p>Projeto esquemático</p><p>Implementação e testes</p><p>Desenvolvimento de projeto</p><p>Construção</p><p>Implantação (sem correspondência)</p><p>Figura 31 – Participação da arquitetura versus fases da engenharia de software</p><p>Participação da arquitetura dentro do ciclo de vida do projeto:</p><p>•	 Pré-projeto:	 é	 comum	 observarmos	 que	 a	 arquitetura	 de	 software participa do ciclo de</p><p>vida de desenvolvimento apenas a partir da fase de projetos. No entanto, é aconselhável</p><p>85</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>que o arquiteto, ou a equipe de arquitetura, participe como observador na fase de análise</p><p>de requisitos. Essa participação é importante, pois possibilita a extração de informações</p><p>técnicas importantes por exemplo, padrões de arquitetura corporativa para integração de</p><p>sistemas, que podem ser importantes para mitigação de custo, tempo de desenvolvimento e</p><p>perfil da equipe.</p><p>•	 Análise	de	domínio:	o	entendimento	dos	requisitos	funcionais	fundamentais	é	ponto	crucial	para</p><p>definição do modelo de domínio que será utilizado como entrada para a fase de projeto, como</p><p>vimos nas unidades anteriores.</p><p>•	 Projeto	esquemático:	criação	ou	seleção	de	um	modelo	de	arquitetura.	Nessa	fase	o	arquiteto</p><p>deve criar ou escolher um modelo arquitetural que irá direcionar o processo de modelagem</p><p>arquitetural e o desenvolvimento.</p><p>•	 Desenvolvimento	 do	 projeto:	 nessa	 fase	 ocorre	 a	 escolha	 de	 elementos	 tecnológicos,	 como</p><p>frameworks ou componentes de desenvolvimento, que deem suporte à implementação.</p><p>•	 Construção:	a	implementação	ou	construção	é	orientada	pela	arquitetura.	Ela	irá	orientar</p><p>tecnologias e todo o processo de desenvolvimento no qual os desenvolvedores estarão</p><p>envolvidos.</p><p>O processo de definição da arquitetura também pode ser subdividido em algumas atividades, que são</p><p>extensões das fases que citamos anteriormente. A figura a seguir mostra a sequência de atividades do</p><p>processo de definição de arquitetura sugerido por Albin (2003), e o quadro na sequência contextualiza</p><p>o objetivo de cada fase.</p><p>Entendimento do problema</p><p>Definição do</p><p>contexto do</p><p>sistema</p><p>Identificação dos</p><p>módulos</p><p>Descrição dos</p><p>componentes e</p><p>dos conectores</p><p>Identificação de elementos do</p><p>projeto e seus relacionamentos</p><p>Avaliação da arquitetura</p><p>Alteração da arquitetura</p><p>Figura 32 – Fases do processo de definição de arquitetura</p><p>86</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Quadro 8 – Fases do processo de arquitetura</p><p>Fase Descrição</p><p>Entendimento do problema A fase de entendimento do problema deve ser iniciada, idealmente, na fase</p><p>de análise de requisitos, como dissemos anteriormente.</p><p>Identificação de elementos do</p><p>projeto e seus relacionamentos</p><p>Nesta etapa, estabelecemos uma decomposição do sistema em uma linha de</p><p>base que, inicialmente, divide o sistema baseado nos requisitos funcionais.</p><p>A arquitetura de um aplicativo de software é, muitas vezes, representada</p><p>como um conjunto de módulos ou subsistemas interligados, muitas vezes</p><p>chamados de componentes.</p><p>Estes módulos são construções organizacionais que o código-fonte estrutura,</p><p>mas muitas vezes não são diretamente visíveis no código-fonte.</p><p>O código-fonte é uma abstração de instruções de máquina e padrões</p><p>de dados estruturados em termos de gramática de uma linguagem de</p><p>programação.</p><p>Esta fase também pode ser subdividida em três etapas:</p><p>•	Definição	do	contexto	do	sistema:	o	contexto	do	sistema	ajuda	a	descrever</p><p>a aplicação de uma perspectiva externa ao sistema, ou seja, aos usuários do</p><p>sistema. O contexto do sistema é útil para descrever a finalidade do sistema,</p><p>bem como para identificar as interfaces externas deste sistema; o insumo</p><p>para definir o contexto do sistema é a lista de requisitos inicial.</p><p>•	Identificação	dos	módulos:	os	módulos	são	unidades	de	software (binário</p><p>e fonte). Módulos binários são instanciados em tempo de execução, e</p><p>essas instâncias são chamadas de componentes. Um determinado módulo</p><p>interage com os demais a partir de conectores e ele pode atender a uma</p><p>determinada quantidade de situações e possuir mais de um conector.</p><p>•	Descrição	dos	componentes	e	dos	conectores:	é	importante	a	descrição</p><p>dos componentes, seu comportamento nas mais diversas situações, bem</p><p>como as condições de seu acionamento, que vêm a ser a descrição de seus</p><p>conectores. A partir dessa descrição podemos avaliar se um componente</p><p>possui alto ou baixo acoplamento e alta ou baixa coesão.</p><p>Avaliação da arquitetura A atividade de avaliação da arquitetura tem como objetivo verificar possíveis</p><p>pontos frágeis da arquitetura, para melhoria.</p><p>Alteração da arquitetura A alteração da arquitetura vem em decorrência dos possíveis pontos frágeis</p><p>encontrados na fase de avaliação.</p><p>Saiba mais</p><p>A avaliação de arquitetura de um sistema de software deve, por boa</p><p>prática, seguir um método ou modelo de referência. Um exemplo de modelo</p><p>de referência para avaliação de arquitetura é o ATAM; mais informações</p><p>podem ser encontradas em:</p><p>SOFTWARE ENGINEERING INSTITUTE (SEI). Architecture tradeoff analysis</p><p>method, 2015b. Disponível em: . Acesso em: 4 maio 2015.</p><p>Nos próximos capítulos, daremos ênfase ao detalhamento da fase de identificação de elementos do</p><p>projeto e aos seus relacionamentos.</p><p>87</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>5.2.5 Processo de arquitetura de software em aspectos humanos</p><p>O processo de arquitetura de software, bem como as demais atividades desenvolvidas ao longo de</p><p>todo o ciclo de desenvolvimento do projeto, possuem alta dependência do fator humano.</p><p>Segundo o OpenUP ([s.d.]a), existem alguns interessados no processo de definição de arquitetura de</p><p>um sistema de software: analistas de requisitos, desenvolvedores, gerentes de projetos e arquitetos de</p><p>software.</p><p>Existem algumas divergências quanto à participação do gerente de projetos nesse processo, uma vez</p><p>que se trata de uma atividade de cunho estritamente técnico.</p><p>Na verdade, se levarmos em consideração o papel da arquitetura de software dentro do projeto de</p><p>software, veremos que o gerente de projeto é um dos principais envolvidos no processo de definição</p><p>de arquitetura.</p><p>Lembrete</p><p>O fato de um papel envolver interesse em um processo não quer dizer</p><p>que ele seja responsável direto por desempenhar uma determinada função.</p><p>No caso da arquitetura, lembramos que um de seus principais benefícios</p><p>é auxiliar a gestão do projeto quanto à estimativa de tempo, ao custo e à</p><p>complexidade do projeto; logo, o gerente de projeto é um interessado no</p><p>processo de arquitetura.</p><p>Obviamente, o papel principal durante o projeto arquitetural é do arquiteto de software. Mas, afinal</p><p>de contas, quem é o arquiteto? Quais são suas responsabilidades? Quais são as habilidades necessárias</p><p>para ser um arquiteto de software?</p><p>Para definirmos quem é o arquiteto de software, vamos dividir a visão da seguinte forma:</p><p>primeiramente sob a ótica do projeto em que atua, e depois sob a ótica de sua área de atuação.</p><p>Sob o ponto de vista do projeto em que atua, o arquiteto tem a obrigação de:</p><p>•	 Conhecer	os	aspectos	culturais	do	seu	cliente.</p><p>•	 Conhecer	as	estratégias	de	mercado	do	cliente	e	o	que	ele	pretende	com	software.</p><p>•	 Conhecer	as	limitações	de	tecnologia	e	infraestrutura	do	cliente.</p><p>•	 Conhecer	o	domínio	do	negócio	e	do	problema	sobre	o	qual	pretende	promover	uma	solução.</p><p>88</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Já sob o ponto de vista da área de atuação, o arquiteto tem a obrigação de:</p><p>•	 Manter-se	 constantemente	 atualizado	 a	 respeito	 das	 metodologias,	 tecnologias,	 soluções	 e</p><p>plataformas de desenvolvimento.</p><p>•	 Conhecimento	 nível	 sênior	 em	 engenharia	 de	 software, que compreende conhecimento em</p><p>pessoas, ferramentas e processos inerentes à engenharia de software.</p><p>As responsabilidades do arquiteto no projeto arquitetural, além de converter os requisitos do cliente</p><p>em projeto de software, são:</p><p>•	 Promover	um	estudo	sobre	a	viabilidade	das	 soluções	 técnicas	adotadas,	a	chamada	prova	de</p><p>conceitos.</p><p>•	 Avaliar	as	tendências	tecnológicas,	em	vista	das	soluções	adotadas	no	projeto,	sob	o	ponto	de</p><p>vista de competitividade do produto a ser desenvolvido.</p><p>•	 Buscar	o	aumento	do	tempo	de	vida	útil	do	software.</p><p>6 VISÕES DA ARQUITETURA DE SOFTWARE</p><p>Como vimos, a arquitetura de um sistema de software define os componentes que formarão este</p><p>sistema de software. Estes componentes podem ter o menor nível de composição, dependendo do nível</p><p>de abstração utilizado nessa composição.</p><p>Esses componentes podem ser divididos em dois grupos: estáticos e dinâmicos.</p><p>•	 A	visão	estática	da	arquitetura	promove	a	visão	da	organização	dos	componentes	do	software</p><p>e de suas relações com elementos de dados (banco de dados, arquivos-texto etc.) com sistemas</p><p>de hardware e com outros sistemas de software. Além, claro, de promover a visão de como estes</p><p>componentes se relacionam entre si.</p><p>•	 A	visão	dinâmica	da	arquitetura	promove	a	visão	comportamental	do	sistema	e	de	seus	componentes</p><p>durante a execução de uma determinada ação. Nessa visão, definimos como os componentes do</p><p>sistema reagem a eventos internos e externos e ainda a forma como eles se comunicam entre</p><p>si, ou seja, o protocolo de comunicação interno, e até mesmo como eles se comunicam com</p><p>componentes externos ao domínio do software, chamado de protocolo de comunicação externa.</p><p>6.1 Visão estática</p><p>A definição da estrutura arquitetural estática de uma solução não deve ser uma atividade executada</p><p>de forma aleatória, sem um estudo prévio.</p><p>Projetar uma estrutura de software significa escolher as alternativas de soluções adequadas e</p><p>inerentes ao domínio do problema, e esse domínio possui inúmeras variantes, por exemplo, os aspectos</p><p>89</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>culturais, a limitação tecnológica e de infraestrutura do cliente e a expectativa de competitividade do</p><p>cliente em relação ao software a ser desenvolvido.</p><p>Essas alternativas de soluções devem validadas antes que sejam utilizadas através de provas de</p><p>conceitos (poc) ou mesmo a partir de soluções que tenham sido previamente validadas.</p><p>Soluções previamente validadas podem ser: frameworks, linguagens, estilos e principalmente</p><p>padrões. Definir a arquitetura de software passa principalmente por saber utilizar padrões.</p><p>6.1.1 Utilização de padrões na arquitetura de software</p><p>Utilização de padrões e padronização é um conceito amplamente utilizado por outras engenharias.</p><p>A engenharia civil, por exemplo, possui uma gama de padrões para resolver o problema de distribuição</p><p>elétrica de uma residência, assim como a engenharia elétrica possui um conjunto de soluções-padrão</p><p>para comunicação entre componentes eletrônicos em uma placa de circuito.</p><p>Padrões são determinadas soluções que comprovadamente funcionam para resolver um</p><p>determinado problema. Ressaltamos, aqui, que se trata de determinadas soluções para determinados</p><p>problemas.</p><p>No entanto, pode surgir uma dúvida: uma determinada solução que comprovadamente resolve um</p><p>determinado problema é garantia de solução para outros problemas?</p><p>Esse é o principal dilema para o uso de padrões na arquitetura de software, pois existe a tendência</p><p>em se usar soluções que garantem a resolução de um determinado problema para resolver outros</p><p>problemas.</p><p>Utilizar dessa maneira um padrão na arquitetura de software é como utilizar um medicamento errado</p><p>ou utilizar o medicamento certo em dose errada para o tratamento de uma determinada enfermidade.</p><p>Gamma et al. (1995), uma das principais referências em padrões na arquitetura de software, definem</p><p>padrão como uma solução reutilizável descrita com base em três partes: um contexto, um problema e</p><p>uma solução.</p><p>•	 Contexto:	estende	o	problema	a	ser	solucionado,	apresentando	situações	de	ocorrência	desses</p><p>problemas.</p><p>•	 Problema:	determinado	por	um	sistema	de	forças,	em	que	estas	forças	estabelecem	os	aspectos</p><p>do problema que devem ser considerados.</p><p>•	 Solução:	mostra	como	resolver	o	problema	recorrente	e	como	balancear	as	forças	associadas	a	ele.</p><p>90</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Observação</p><p>Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, autores do</p><p>livro Design Patterns: Elements of Reusable Object-Oriented Software, são</p><p>considerados as maiores autoridades e precursores na utilização de projetos</p><p>em arquitetura de software. Este grupo foi apelidado de gang of four (GoF)</p><p>ou grupo dos quatro e é tratado assim na literatura específica da área.</p><p>A utilização de padrões na arquitetura de software tem como objetivos principais resolver problemas</p><p>macros</p><p>comuns a todos os sistemas de software, como: produtividade, reúso, redução de complexidade</p><p>e geração de um protocolo de comunicação entre todos os envolvidos em um projeto de software. A</p><p>opção pela utilização de um determinado padrão ou de um conjunto de padrões é chamada de decisão</p><p>arquitetural.</p><p>O uso de um conjunto de padrões que resolve um determinado problema é chamado de estilo</p><p>arquitetural ou modelo arquitetural.</p><p>6.1.2 Estilo arquitetural</p><p>Estilo arquitetural, modelo arquitetural ou ainda padrão arquitetural é a organização, em um alto</p><p>nível de abstração, de um sistema de software em um conjunto finito de subsistemas. Essa organização</p><p>especifica as responsabilidades, regras de organização e o relacionamento entre estes subsistemas</p><p>(BUSCHMANN et al., 1996).</p><p>Buschmann et al. (1996) aponta que um padrão arquitetural, além de auxiliar no desenvolvimento da</p><p>estrutura fundamental de um sistema de software, auxilia no atendimento de um atributo de qualidade</p><p>deste sistema, por exemplo, manutenibilidade.</p><p>O benefício da aplicação de um estilo arquitetural dá-se pela capacidade de reúso; logo, pela</p><p>produtividade que ele proporciona.</p><p>Um estilo arquitetural visa à solução de um problema em um determinado contexto, todavia tem</p><p>sua ênfase no nível estrutural da solução, não adentrando o nível de implementação, razão que lhe</p><p>confere maior possibilidade de reúso no caso de este problema também existir em um contexto de</p><p>negócio diferente do original (BUSCHMANN et al., 1996).</p><p>Os principais estilos arquiteturais, extraídos de Buschmann et al. (1996), são classificados em quatro</p><p>categorias. Essas categorias representam contextos de problemas com características similares, por</p><p>exemplo, a necessidade de separação do sistema em componentes ou a necessidade de apoiar melhor a</p><p>interação humano-computador, e um estilo pode se encaixar em mais de uma classificação. O seguinte</p><p>mostra o agrupamento desses estilos e uma breve descrição de cada estilo arquitetural.</p><p>91</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Quadro 9 – Estilos arquiteturais</p><p>Categoria Estilo arquitetural</p><p>From mud to structure</p><p>(Da “lama” à estrutura)</p><p>Camadas ou Layers</p><p>Pipes and Filters</p><p>Blackboard</p><p>Sistemas distribuídos</p><p>Broker</p><p>Microkernel</p><p>Pipes and Filters</p><p>Sistemas interativos</p><p>Model-View-Controller (MVC)</p><p>Presentation-Abstraction-Control (PAC)</p><p>Sistemas adaptáveis</p><p>Reflection</p><p>Microkernel</p><p>•	 Camadas	ou	Layers: padrão que promove a divisão em níveis de abstração, em que o critério para</p><p>essa divisão é a responsabilidade de cada nível, ou camada (BUSCHMANN et al., 2007).</p><p>•	 Pipes and Filters: este padrão promove a divisão de cada atividade da aplicação em um passo</p><p>a passo de processamento de informações. Cada passo é uma unidade de processamento que</p><p>recebe, processa e devolve uma informação que serve de entrada para o próximo. Esse processo</p><p>gera uma cadeia denominada pipeline (BUSCHMANN et al., 2007).</p><p>•	 Blackboard: neste padrão são montadas soluções para uma tarefa através do uso da heurística</p><p>computacional. Essas soluções são chamadas hipóteses e são alimentadas gradualmente através</p><p>de algoritmos de pequenos componentes do sistema e armazenadas em uma área de memória</p><p>chamada blackboard. A solução da tarefa é colaborativa, dada pelo conjunto dessas hipóteses,</p><p>originadas de um conjunto de componentes da aplicação (BUSCHMANN et al., 2007).</p><p>•	 Broker: promove o encapsulamento de detalhes da infraestrutura de comunicação e a separação</p><p>desta das funcionalidades da aplicação (BUSCHMANN et al., 2007).</p><p>•	 Microkernel: promove a criação de um componente fechado com todos os serviços fundamentais</p><p>para a aplicação, esse componente é chamado microkernel. Outras funcionalidades específicas</p><p>são distribuídas em outros componentes da aplicação (BUSCHMANN et al., 2007).</p><p>•	 Model-View-Controller (MVC): propõe a divisão lógica da aplicação em três camadas: model, view</p><p>e controller. A camada Model ou modelo é responsável por objetos que representem o domínio</p><p>da aplicação, por exemplo, as regras de negócio; a camada View ou visão representa a interface</p><p>com o usuário; e a camada Controller tem como objetivo o gerenciamento do fluxo da aplicação</p><p>(BUSCHMANN et al., 2007).</p><p>•	 Presentation-Abstraction-Control (PAC): propõe a divisão da aplicação em componentes, em que</p><p>cada qual tem três divisões lógicas: presentation, abstraction e control. A camada Presentation ou</p><p>92</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>apresentação é responsável pela interface com o usuário, a camada Abstraction ou abstração</p><p>é responsável por objetos que representam o domínio da aplicação, por exemplo, as regras de</p><p>negócio, e a camada Control ou controle é responsável pelo fluxo da solução e comunicação</p><p>entre os componentes da solução. O padrão PAC difere do MVC em um ponto: permite que cada</p><p>componente seja uma célula de processamento, ou thread independente; pode-se dizer que</p><p>cada componente é uma implementação do padrão MVC (COUTAZ, 1987).</p><p>•	 Reflection: propõe a separação da aplicação em duas camadas, denominadas metanível e nível-base.</p><p>A camada metanível tem os chamados meta-objetos, que são objetos cujas responsabilidades estão</p><p>ligadas a características estruturais, comportamentais e de estados da aplicação. A camada-base</p><p>contém as funcionalidades da aplicação (BUSCHMANN et al., 2007).</p><p>Observação</p><p>Esta disciplina não tem como objetivo principal a formação de arquiteto</p><p>de software; para tal, é preciso maior especialização em algumas áreas e</p><p>disciplinas específicas. Nosso objetivo principal é fazer você ter o primeiro</p><p>contato com o tema e na sua vida profissional saiba entender e seguir um</p><p>estilo adotado em um sistema de software.</p><p>De todos esses estilos, nos aprofundaremos em um dos estilos arquiteturais mais utilizados</p><p>atualmente: arquitetura em camadas, que tem sua importância por ser uma arquitetura-base para</p><p>outros estilos, como MVC e PAC.</p><p>6.1.3 Estruturação de sistemas em subsistemas e camadas</p><p>Antes de explorarmos a solução, vamos debater um pouco do problema que teremos de resolver.</p><p>Imagine a seguinte situação: você é contratado para desenvolver um simples sistema de cadastro de</p><p>funcionários. Nesse sistema, terá apenas de inserir informações básicas de um funcionário, como nome,</p><p>CPF, RG, número do PIS e salário; no requisito salário, o usuário do sistema entra com o salário bruto</p><p>e o sistema automaticamente calcula o salário líquido a partir de algumas regras como desconto de</p><p>imposto de renda e INSS. Suponhamos ainda que esse sistema seja um sistema web.</p><p>Você então desenvolve uma página web e dentro dessa página você desenvolve as regras de negócio</p><p>para cálculo, validações de campos obrigatórios, de consistência de CPF, efetua conexão com o banco</p><p>de dados e insere um registro no repositório de informações.</p><p>Até o momento, aparentemente, tudo está normal, afinal de contas, todos os requisitos do usuário</p><p>foram atendidos e o sistema se dispõe a resolver o problema proposto.</p><p>Imaginemos agora que nesse sistema seja acrescido o cadastro de plano de previdência privada,</p><p>que está associado ao salário líquido do funcionário. Aparentemente, não há problema algum, exceto</p><p>93</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>pelo fato de que você não terá como reutilizar o código para implementar o cálculo do salário líquido</p><p>do funcionário, o que não aparenta ser um grande problema, pois você pode copiar e colar o código de</p><p>uma página para outra.</p><p>Agora o sistema está funcionando normalmente, a operação dia a dia ocorre sem mais problemas,</p><p>até que um determinado dia ocorre uma mudança.</p><p>É comum a ocorrência de mudanças na legislação, que acabam por acarretar modificações nos</p><p>sistemas de informação que porventura</p><p>utilizem ou trabalhem com informações governamentais.</p><p>Pois bem, eis que ocorre uma mudança hipotética no cálculo do imposto de renda e do INSS, o que</p><p>interfere diretamente no cálculo do salário líquido dos funcionários.</p><p>Aproveitando esse momento, seu cliente decide, já que o sistema será alterado, solicitar algumas</p><p>mudanças no layout das páginas web, como mudança no padrão de cores, imagens e melhoria na</p><p>usabilidade. Já que estamos em um momento de mudança, o diretor de TI do seu cliente decide resolver</p><p>um antigo problema: a mudança do fornecedor do SGDB e a padronização dos nomes das tabelas do</p><p>banco de dados.</p><p>As alterações não parecem complexas e na verdade elas realmente não são, todavia você esbarra,</p><p>agora, em alguns problemas:</p><p>•	 Você	não	se	lembra	em	quantos	pontos	do	código	a	regra	de	cálculo	de	salário	líquido	é	executada.</p><p>O sistema cresceu demais, outras páginas foram criadas, outras regras, implementadas, enfim,</p><p>você terá de procurar todos os pontos, alterá-los e testá-los.</p><p>•	 Você	tem	um	alto	acoplamento	de	fatores	que	não	têm	nenhuma	relação,	como	o	banco	de	dados</p><p>e suas páginas web. Como a parte de banco de dados está na página web, você acabou criando</p><p>uma dependência indireta de componentes que não necessitam um do outro para funcionar. Na</p><p>prática, a mudança no banco de dados não deveria influenciar a sua página web, mas, da forma</p><p>como está construído, você necessariamente terá de testar tudo novamente, uma vez que haverá</p><p>alteração no código-fonte da página.</p><p>•	 Você	monta	um	cronograma	com	as	atividades	sequenciais,	aumentando	o	custo	da	manutenção.</p><p>Por quê? Porque é impossível dividir e paralelizar as tarefas de alteração da regra de negócio do</p><p>cálculo de impostos, a alteração das páginas e a alteração do banco de dados, uma vez que todas</p><p>elas serão feitas nos mesmos componentes do software, ou seja, nas páginas web.</p><p>O problema por que você está passando, infelizmente, é muito comum de encontrar na nossa vida</p><p>profissional. O seu sistema possui:</p><p>•	 Alto	 acoplamento	 e	 baixa	 coesão:	 quando	 existem	 dependências	 demais	 de	 tecnologias	 e</p><p>componentes que, em tese, não deveriam depender, pois possuem independência funcional umas</p><p>das outras.</p><p>94</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>•	 Baixa	manutenibilidade:	ocorre	quando	a	sua	produtividade	na	manutenção	é	baixa,	você	tem</p><p>de procurar todos os pontos do código que devem ser alterados e é impossível que se altere um</p><p>componente sem que o todo seja afetado.</p><p>•	 Baixo	reúso:	é	quando	seu	sistema	basicamente	não	possui	reúso,	lembrando	que	copiar	e	colar</p><p>um trecho de código não pode ser considerado reúso, mas, meramente, uma cópia, uma facilidade</p><p>para que você não precise digitar todo o código novamente.</p><p>Imaginemos então que pudéssemos separar em uma “caixa” todas as classes que fossem</p><p>relacionadas a páginas web, em uma segunda “caixa” todas as classes que executassem algum</p><p>tipo de regra de negócio e em uma terceira todas as classes que fizessem interface com o banco</p><p>de dados, e que essas “caixas” tivessem um protocolo de comunicação entre elas, como mostra a</p><p>figura a seguir:</p><p>Páginas web</p><p>Regras de negócio</p><p>Banco de dados</p><p>Figura 33 – Organização em “caixas”</p><p>Neste caso, teríamos resolvido alguns problemas:</p><p>•	 Divisão	de	responsabilidades:	cada	“caixa”	teria	uma	responsabilidade	bem-definida.</p><p>•	 Baixo	 acoplamento:	 as	 “caixas”	 teriam	 apenas	 as	 dependências	 necessárias,	 por	 exemplo,	 as</p><p>páginas web não precisariam depender do banco de dados e vice-versa.</p><p>•	 Boa	 manutenibilidade:	 agora	 é	 possível	 saber	 exatamente	 em	 que	 “caixa”	 se	 encontram	 os</p><p>componentes responsáveis por fazer algum tipo de cálculo ou executar alguma regra de negócio,</p><p>bem como é possível paralelizar as atividades, cada equipe cuida da manutenção de uma “caixa”:</p><p>uma cuida do banco de dados, outra das páginas web e uma terceira das mudanças nas regras de</p><p>negócio. O trabalho é mais produtivo.</p><p>•	 Reúso:	 os	 componentes	 podem	 ser	 reutilizáveis,	 ou	 seja,	 você	 pode	 simplesmente	 usar	 um</p><p>componente da “caixa” regra de negócio de quantas páginas web você quiser, com a certeza de</p><p>que o código implementado é o mesmo, sem ter de utilizar o artifício de copiar o código.</p><p>95</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Notamos que a simples decomposição das classes e a organização delas em estruturas conceituais</p><p>de acordo com as suas responsabilidades já resolve boa parte dos problemas.</p><p>É como se dividíssemos o nosso sistema em camadas, em que cada “caixa” corresponde a uma</p><p>camada. Esse é o estilo arquitetural de camadas, ou arquitetura três camadas, que possui a estrutura</p><p>final, representada na figura a seguir:</p><p>Camada de apresentação</p><p>Ob</p><p>je</p><p>to</p><p>s d</p><p>e</p><p>ne</p><p>gó</p><p>ci</p><p>o</p><p>Camada de negócios</p><p>Camada de integração</p><p>Figura 34 – Arquitetura em camadas</p><p>Nesta arquitetura temos três camadas principais:</p><p>•	 Camada	de	apresentação:	que	contém	classes	responsáveis	pela	interação	com	o	usuário,	como</p><p>páginas web, formulários etc.</p><p>•	 Camada	de	negócios:	que	contém	classes	responsáveis	por	execução	de	regras	de	negócio,	como</p><p>cálculos, validações etc.</p><p>•	 Camada	de	 integração:	que	contém	classes	responsáveis	por	fazer	 integração	com	tecnologias</p><p>externas ao sistema, como banco de dados, serviços web, além de outros sistemas ou dispositivos</p><p>de hardware.</p><p>Definimos que as camadas se comunicarão através de um protocolo e que esse protocolo é definido</p><p>pela camada auxiliar de objetos de negócio. Essa camada é composta por objetos cuja finalidade é</p><p>apenas transportar informação, sem executar nenhuma regra, sem fazer nenhuma interface externa.</p><p>São as nossas classes do tipo entidade, ou entity.</p><p>No nosso exemplo, poderíamos ter nessa camada uma classe “Funcionário” apenas com os atributos:</p><p>nome, CPF, RG, número do PIS, salário bruto e salário líquido:</p><p>96</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Funcionario</p><p>+ nome: String</p><p>+ CPF: int</p><p>+ RG: int</p><p>+ salario_bruto: double</p><p>+ salario_liquido: double</p><p>Figura 35 – Classe “Funcionario”</p><p>Lembrete</p><p>Podemos atribuir responsabilidades às classes em um modelo de projeto,</p><p>que são: entidade (entity), controle (control) e fronteira (boundary).</p><p>Ainda na linha das responsabilidades das classes, seria correto afirmar que, nas camadas de</p><p>integração e de apresentação, teremos única e exclusivamente objetos do tipo fronteira (boundary),</p><p>e, na camada de negócios, apenas objetos do tipo controle (control).</p><p>A arquitetura em camadas é muito importante; por ora, direcione seus esforços a entender o</p><p>conceito, que é simples.</p><p>Saiba mais</p><p>Aprofunde seus conhecimentos sobre arquitetura em camadas</p><p>utilizando a plataforma Microsoft .Net em:</p><p>.</p><p>6.1.4 Introdução a padrões de projeto (design patterns)</p><p>Padrão de projeto, ou design pattern, é a menor estrutura arquitetural proveniente dos subsistemas</p><p>de um sistema de software e do relacionamento entre eles (BUSCHMANN et al., 1996).</p><p>É semelhante aos estilos arquiteturais em todos os pontos, todavia difere pelo nível de abstração.</p><p>Ao passo que um estilo arquitetural tem ênfase no nível estrutural da solução, o padrão de projeto</p><p>tem ênfase na estrutura do subsistema da solução (BASS; CLEMENTS; KAZMAN, 2010; BUSCHMANN</p><p>et al., 1996).</p><p>A exemplo do estilo arquitetural, o padrão de projeto não entra no nível de implementação, sendo</p><p>independente de qualquer tipo de tecnologia ou linguagem, razão pela qual possibilita seu reúso em</p><p>97</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>diversos contextos de problemas, além de promover a redução da complexidade da solução através</p><p>da decomposição de</p><p>subsistemas de maior complexidade em componentes de menor complexidade</p><p>(BUSCHMANN et al., 1996).</p><p>Gamma et al. (1995) propõem um catálogo com 23 padrões de projetos, organizados em quatro</p><p>categorias, que representam contextos de uso com características similares. O quadro a seguir mostra</p><p>o agrupamento desses padrões:</p><p>Quadro 10 – Padrões de projeto</p><p>Categoria Padrão de projeto</p><p>Padrões para criação</p><p>Abstract factory</p><p>Builder</p><p>Factory method</p><p>Prototype</p><p>Singleton</p><p>Padrões estruturais</p><p>Adapter</p><p>Bridge</p><p>Composite</p><p>Decorator</p><p>Facade</p><p>Flyweight</p><p>Proxy</p><p>Padrões comportamentais</p><p>Chain of responsibility</p><p>Command</p><p>Interpreter</p><p>Iterator</p><p>Mediator</p><p>Memento</p><p>Observer</p><p>State</p><p>Strategy</p><p>Template method</p><p>Visitor</p><p>Segue uma breve descrição de cada padrão de projeto apresentado no quadro anterior:</p><p>•	 Abstract factory: padrão que provê uma interface para criação de famílias de objetos relacionados</p><p>ou dependentes sem que haja necessidade de discriminação de suas classes concretas (GAMMA et</p><p>al., 1995).</p><p>98</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>•	 Builder: propõe a separação da construção de um objeto complexo de sua representação, assim,</p><p>o mesmo processo de criação pode criar diferentes representações (GAMMA et al., 1995).</p><p>•	 Factory method: padrão que provê uma interface para criação de um objeto, esta atividade fica a</p><p>cargo de subclasses, que decidem quais classes devem ser instanciadas (GAMMA et al., 1995).</p><p>•	 Prototype: propõe a criação de objetos através da instância de um protótipo. Instâncias de novos</p><p>objetos são criadas pela cópia deste protótipo (GAMMA et al., 1995).</p><p>•	 Singleton: padrão que promove a garantia de que uma classe terá uma única instância dentro da</p><p>aplicação e propõe um ponto de acesso único de todos os pontos da aplicação à instância dessa</p><p>classe (GAMMA et al., 1995).</p><p>•	 Adapter: propõe a conversão da interface de uma classe para outra interface esperada pelo cliente</p><p>(GAMMA et al., 1995).</p><p>•	 Bridge: promove a separação da abstração de uma classe de sua implementação (GAMMA et al.,</p><p>1995).</p><p>•	 Composite: padrão que propõe a composição de um objeto em uma árvore hierárquica que</p><p>representa o conceito todo/parte desse objeto (GAMMA et al., 1995).</p><p>•	 Decorator: propõe que comportamentos sejam adicionados a um objeto de forma dinâmica</p><p>(GAMMA et al., 1995).</p><p>•	 Facade: padrão que provê um ponto único de interface para um conjunto de interfaces de</p><p>subsistemas (GAMMA et al., 1995).</p><p>•	 Flyweight: este padrão propõe a criação de um objeto compartilhado que pode ser usado em</p><p>múltiplos contextos simultaneamente, com o objetivo de apoiar o uso de um grande número de</p><p>objetos de menor granularidade de forma eficiente (GAMMA et al., 1995).</p><p>•	 Proxy: este padrão propõe que um objeto crie um mecanismo para controlar o acesso de outro</p><p>objeto a seus recursos (GAMMA et al., 1995).</p><p>•	 Chain of responsability: propõe a separação de um objeto remetente de uma solicitação ao seu</p><p>destinatário, dando a mais de um objeto a capacidade de receber essa solicitação. Esses objetos</p><p>são colocados em uma cadeia, e a solicitação é passada de um a outro até que o destinatário a</p><p>receba (GAMMA et al., 1995).</p><p>•	 Command: propõe a abstração de uma requisição como um objeto. Possibilita parametrização de</p><p>clientes com diferentes requisições, filas ou armazenamento dessas informações em formato de</p><p>log e ainda apoia operações que podem ser desfeitas (GAMMA et al., 1995).</p><p>99</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>•	 Interpreter: esse padrão descreve como definir uma representação para uma determinada</p><p>linguagem, representar sentenças nesta linguagem e interpretar essas sentenças (GAMMA et</p><p>al., 1995).</p><p>•	 Iterator: propõe um ponto de acesso a elementos de um objeto agregado ou uma lista de objetos</p><p>de forma sequencial sem que haja necessidade de exposição de detalhes da implementação desses</p><p>elementos (GAMMA et al., 1995).</p><p>•	 Mediator: propõe a criação de um objeto que encapsule a forma de interação de um conjunto de</p><p>outros objetos (GAMMA et al., 1995).</p><p>•	 Memento: propõe o armazenamento de um objeto interno sem que haja violação de</p><p>encapsulamento, para que esse objeto possa ser recuperado a este estado futuramente (GAMMA</p><p>et al., 1995).</p><p>•	 Observer: padrão que propõe a composição de um objeto em uma árvore hierárquica de objetos</p><p>dependentes. Quando este objeto muda de estado, todos os objetos desta árvore são notificados,</p><p>e seu estado é atualizado automaticamente (GAMMA et al., 1995).</p><p>•	 State: este padrão propõe que um objeto altere seu comportamento assim que seu estado muda,</p><p>o efeito é como se a classe do objeto mudasse (GAMMA et al., 1995).</p><p>•	 Strategy: propõe a criação de uma família de algoritmos encapsulados e intercambiáveis que são</p><p>acessados independentemente do cliente que os utiliza por uma interface-padrão denominada</p><p>strategy (GAMMA et al., 1995).</p><p>•	 Template method: este padrão propõe que uma subclasse redefina certos passos de um algoritmo</p><p>sem que haja mudança na estrutura deste algoritmo (GAMMA et al., 1995).</p><p>•	 Visitor: este padrão promove a criação de novas operações através da adição de subclasses na</p><p>hierarquia da classe na qual essa nova operação irá atuar (GAMMA et al., 1995).</p><p>Saiba mais</p><p>Para aprofundar seus conhecimentos em padrões de projeto, consulte:</p><p>BUSCHMANN, F.; HENNEY, K.; SCHIMIDT, D. Pattern-oriented software</p><p>architecture: a pattern language for distributed computing. New York:</p><p>Wiley, 2007. v. 4.</p><p>GAMMA, E. et al. Design patterns: elements of reusable object-oriented</p><p>software. Boston: Addison-Wesley, 1995.</p><p>100</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>A maneira mais simples de entender e assimilar design pattern é buscar um padrão dentro deste</p><p>catálogo, entender qual é seu objetivo, ler o seu modelo de classes e implementar, na forma de prova de</p><p>conceito, na linguagem orientada a objetos de nossa preferência.</p><p>Lembrete</p><p>A implementação de padrões de projeto, ou design pattern, é</p><p>independente da linguagem de programação. Essa é uma das grandes</p><p>vantagens de utilizarmos padrões.</p><p>O padrão Singleton, por exemplo, tem por objetivo utilizar uma única instância de uma classe em</p><p>todo o sistema. A figura seguinte representa a documentação do padrão Singleton.</p><p>Singleton</p><p>- instance: Singleton</p><p>- Singleton()</p><p>+ getInstance(): Singleton</p><p>Figura 36 – Padrão Singleton</p><p>Agora vamos entender cada ponto que o padrão sugere:</p><p>•	 Repare	que	o	construtor	da	classe	é	privado.	Por	que	privado?	Porque	nenhum	outro	objeto	terá</p><p>acesso a esse construtor, logo não poderá instanciar essa classe.</p><p>•	 Temos	um	método	público	(e	estático),	de	nome	getInstance, que retorna um objeto do tipo da</p><p>própria classe em que está criado. Por que público e por que estático? Público para que outros</p><p>objetos possam acessar e estático para que ele possa ser chamado sem que haja necessidade de</p><p>instanciar a classe em que ele está declarado.</p><p>•	 Temos	um	atributo	privado,	de	nome	instance, do tipo da própria classe em que está criado. Por</p><p>que do tipo da própria classe? Para que possamos armazenar uma instância dessa classe.</p><p>Quando estamos entendendo padrões de projeto, é importante que não deixemos passar despercebido</p><p>nenhum detalhe, por exemplo, a visibilidade dos atributos, métodos e construtores.</p><p>101</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>A figura seguinte mostra a implementação desta classe utilizando Microsoft .Net C#.</p><p>Figura 37 – Implementação Singleton em C#</p><p>Na figura apresentada, podemos notar que o detalhe está na implementação do método getInstance,</p><p>no qual se verifica se a variável responsável por armazenar a instância da classe é nula; em caso</p><p>positivo,</p><p>cria-se a instância (para primeira utilização), e, caso contrário, retorna-se a instância, garantindo assim</p><p>que essa classe seja instanciada apenas na primeira vez.</p><p>Saiba mais</p><p>Aprofunde seus estudos sobre design pattern com o livro:</p><p>FREEMAN, E et al. Head first design patterns. Sebastopol: O’Reilly, 2004.</p><p>Saiba como implementar padrões de projeto utilizando o Microsoft .Net</p><p>Framework em:</p><p>DOFACTORY. .NET design pattern framework 4.5, [s.d.]. Disponível em:</p><p>.</p><p>Acesso em: 4 maio 2015.</p><p>6.2 Visão dinâmica</p><p>O objetivo principal da visão dinâmica da arquitetura é representar a realização dos casos de uso,</p><p>que fundamentalmente se dá pela troca de mensagens entre os objetos no decorrer do tempo.</p><p>O primeiro passo para se determinar como uma tarefa será executada é definir as responsabilidades</p><p>de cada objeto.</p><p>102</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>6.2.1 Definindo responsabilidades</p><p>Como vimos, o estilo arquitetural em camadas tem, entre outros objetivos, o de subdividir e agrupar</p><p>as classes em grupos de acordo com as suas responsabilidades.</p><p>Vimos que, ao fazer isso, classificamos as classes como: entidade (entity), controle (control) e fronteira</p><p>(boundary) e cada uma delas possui uma atribuição bem-definida no contexto do sistema.</p><p>Voltando ao exemplo do cadastro de funcionários, após a reorganização (também chamada de refactory)</p><p>do seu sistema, suponhamos que você tenha chegado ao seguinte modelo de classes de projeto:</p><p>></p><p>Funcionario</p><p>+ nome: String</p><p>+ CPF: int</p><p>+ RG: int</p><p>+ salario_bruto: double</p><p>+ salario_liquido: double</p><p>></p><p>PaginaWebNovoFuncionario</p><p>+ cadastrarFuncionario() : void</p><p>></p><p>FuncionarioNegocio</p><p>+ incluirFuncionario(Funcionario) : void</p><p>+ calcularSalarioLiquido(double) : double</p><p>></p><p>FuncionarioDados</p><p>+ incluirFuncionario(Funcionario) : void</p><p>Figura 38 – Modelo de classes de projeto com responsabilidades</p><p>Note que agora temos todas as classes referentes ao nosso problema: a página web</p><p>(“PaginaWebNovoFuncionario”), a classe responsável pelas regras de negócio (“FuncionarioNegocio”), a</p><p>classe responsável pelo armazenamento dos dados no banco de dados (“FuncionarioDados”) e a nossa</p><p>entidade “Funcionario”.</p><p>No entanto, ainda precisamos representar o fluxo de mensagens dessas entidades. É necessário</p><p>representar quais objetos estão envolvidos em uma troca de mensagens, quais são essas mensagens</p><p>trocadas e o significado dessas mensagens. Precisamos, por exemplo, saber qual evento da tela é o</p><p>gatilho para todo o processo de cadastrar funcionário.</p><p>Para isso, precisamos pegar os conceitos e os diagramas de sequência que fizemos até então e</p><p>adaptá-los, refiná-los adicionando as novas classes e as suas respectivas responsabilidades.</p><p>103</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>6.2.2 Refinando o diagrama de sequência</p><p>Antes de refinar o diagrama de sequência, precisamos saber como representamos as classes, ou</p><p>objetos, de acordo com suas respectivas responsabilidades no diagrama de sequência. A figura a seguir</p><p>mostra os estereótipos utilizados nessa representação.</p><p>Fronteira Controle Entidade</p><p>Figura 39 – Estereótipos de responsabilidades no diagrama de sequência</p><p>Agora podemos refinar ou desenvolver o diagrama de sequência representando corretamente as</p><p>classes, suas respectivas responsabilidades e os significados de suas mensagens, como mostra o exemplo</p><p>da figura a seguir que representa a visão dinâmica do processo de cadastrar funcionário:</p><p>Usuário</p><p>: PaginaWebNovoFuncionario : Funcionario : FuncionarioNegocio : FuncionarioDados</p><p>: cadastrarFuncionario()</p><p>create()</p><p>incluirFuncionario(Funcionario)</p><p>incluirFuncionario(Funcionario)</p><p>calcularSalarioLiquido(double): double</p><p>Figura 40 – Diagrama de sequência refinado</p><p>104</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>6.3 Documentação de arquitetura</p><p>Como vimos, um sistema de software é um conjunto de componentes dispostos em uma estrutura,</p><p>que diz como eles estão arranjados, suas composições, dependências e ainda como eles se relacionam</p><p>para resolver um determinado problema, além de definir como estes componentes estão distribuídos em</p><p>uma infraestrutura (BASS; CLEMENTS; KAZMAN, 2010).</p><p>Visões arquiteturais são representações de cada uma dessas estruturas, e cada uma dessas visões</p><p>terá uma forma específica de documentação. Neste livro-texto utilizaremos a documentação das visões</p><p>arquiteturais a partir da UML.</p><p>Saiba mais</p><p>Existem outras abordagens de documentação de arquitetura, por</p><p>exemplo, o modelo RMODP. Para aprofundar seus conhecimentos sobre</p><p>esse modelo, leia:</p><p>INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). 10746-3:</p><p>open distributed processing – reference model. Geneve: ISO, 2009.</p><p>Segundo Bass, Clements e Kazman (2010), são três as visões arquiteturais:</p><p>•	 Visão	modular:	 representa	a	visão	do	sistema	em	termos	de	unidade	de	 implementação;	essas</p><p>unidades podem ser classes, componentes ou módulos.</p><p>•	 Visão	componente	e	conector:	representa	a	forma	pela	qual	os	componentes	interagem,	ou	seja,</p><p>seus protocolos de comunicação.</p><p>•	 Visão	de	alocação:	representa	a	forma	pela	qual	esses	componentes	estão	distribuídos	em	uma</p><p>infraestrutura.</p><p>Para cada uma dessas visões, temos um diagrama, ou um conjunto bem-definido de diagramas da</p><p>UML que nos auxiliam na modelagem e na documentação.</p><p>Por ora, atente-se em saber quais diagramas são utilizados para cada uma das visões; adiante,</p><p>detalharemos cada um deles. O quadro seguinte mostra a relação entre os diagramas da UML e as visões</p><p>arquiteturais.</p><p>105</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Quadro 11 – Diagramas UML e visões arquiteturais</p><p>Visão arquitetural Diagrama UML</p><p>Visão modular Diagrama de pacotes</p><p>Diagrama de classes</p><p>Visão componente e conector Diagrama de componentes</p><p>Visão de alocação Diagrama de distribuição</p><p>Além dos diagramas referentes às visões arquiteturais, que têm como função principal representar a</p><p>visão estática da arquitetura, temos de documentar a visão dinâmica da arquitetura.</p><p>Para isso, é preciso um conjunto de diagramas da UML que servem como complemento ao diagrama</p><p>de sequência, que vem a ser o principal diagrama para documentarmos a visão dinâmica de uma</p><p>arquitetura.</p><p>Os diagramas a seguir são utilizados para documentar a visão dinâmica de uma arquitetura:</p><p>•	 Diagrama	de	sequência.</p><p>•	 Diagrama	de	colaboração.</p><p>•	 Diagrama	de	máquinas	de	estado.</p><p>Observação</p><p>A documentação da arquitetura não se resume apenas no</p><p>desenvolvimento de diagramas UML. É importante que tenhamos uma</p><p>organização e uma gestão de conteúdo que faça o relacionamento entre</p><p>os diagramas produzidos e seus significados para o sistema, casos de uso</p><p>que se deseja resolver e justificativas de solução.</p><p>Resumo</p><p>Nesta unidade, abordamos o ciclo de vida das atividades referentes ao</p><p>projeto.</p><p>Lembramos que o ciclo de vida das atividades de projeto é dividido em</p><p>quatro atividades: projeto de classes e dados, projeto arquitetural, projeto</p><p>de interfaces e projeto de componentes.</p><p>106</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>A fase de projeto de dados tem o objetivo de definir um dicionário de</p><p>dados, uma estrutura de informação necessária para a implementação</p><p>de um sistema de software. Nesta fase, a ênfase dá-se em projetar um</p><p>banco de dados.</p><p>Projetar um banco de dados é algo que não deve ser feito a esmo, e,</p><p>como vimos, o projeto é dividido em três fases: projeto conceitual, projeto</p><p>lógico e projeto físico.</p><p>A fase de projeto</p><p>conceitual tem como objetivo produzir um modelo</p><p>de alto nível de abstração que represente a estrutura do banco de</p><p>dados; o projeto lógico tem como objetivo refinar este modelo de tal</p><p>forma que acrescente detalhes inerentes ao SGBD; e o projeto físico</p><p>tem como objetivo pegar este modelo e convertê-lo em um modelo</p><p>no nível do SGBD; esta é a fase mais associada à tecnologia de todo o</p><p>processo.</p><p>Na atualidade o modelo de dados relacional é um dos modelos mais</p><p>utilizados em projetos de banco de dados, e, por isso, a ênfase foi dada à</p><p>produção do modelo entidade relacionamento ou MER.</p><p>O MER é baseado em três pilares: as entidades, que são representações</p><p>de entidades do mundo real, seus atributos ou características, e o</p><p>relacionamento entre essas entidades.</p><p>Vimos que a adaptação do MER ao paradigma da orientação a objetos</p><p>requer alguns cuidados, principalmente, porque o MER não possui</p><p>características fundamentais à orientação a objetos, como armazenamento</p><p>de métodos e herança.</p><p>Em contrapartida, esses paradigmas possuem semelhanças: os conceitos</p><p>de entidades e atributos, que são análogos aos de classes e atributos, e o</p><p>conceito de identidade de entidade, que pode ser considerado análogo ao</p><p>conceito de identidade da orientação a objetos.</p><p>De qualquer forma, uma alternativa viável para armazenarmos os</p><p>objetos em um modelo relacional é fazer um mapeamento de quais classes</p><p>devem ser persistidas na base de dados; boas classes candidatas a isso são</p><p>as do tipo entidade (entity).</p><p>Após a fase de projeto de dados e classes, passamos a debater a fase de</p><p>projeto arquitetural.</p><p>107</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Vimos que, analogamente à engenharia civil, a arquitetura, na</p><p>engenharia de software, tem papel fundamental, apesar de nem sempre</p><p>ser valorizada pelas organizações.</p><p>É na arquitetura de software que se projetam as estruturas, a</p><p>constituição de um software que servirá como base fundamental para a</p><p>fase de construção.</p><p>Existem muitas definições de arquitetura de software, na visão de</p><p>Bass, Clements e Kazman (2010), que são uma das melhores referências</p><p>no tema. Ela pode ser definida como uma representação, em alto nível de</p><p>abstração, dos componentes de um sistema de software, as propriedades</p><p>externamente visíveis destes componentes e como eles interagem com o</p><p>objetivo de resolver as necessidades, ou o problema, de um determinado</p><p>cenário de negócio (BASS; CLEMENTS; KAZMAN, 2010).</p><p>A arquitetura é muito importante, pois facilita a comunicação entre os</p><p>envolvidos no projeto, representa em escala menor a estrutura do sistema,</p><p>evidencia as decisões de projeto, além de facilitar a evolução, o reúso e a</p><p>manutenção do software.</p><p>Existe uma lacuna entre a arquitetura e o gerenciamento de projeto que,</p><p>como debatemos, não deveria existir, uma vez que a arquitetura auxilia a gestão</p><p>do projeto quanto à estimativa de tempo, ao custo e à complexidade do projeto,</p><p>além de auxiliá-la na mitigação e na diminuição de riscos.</p><p>Vimos que o processo de definição da arquitetura de um software,</p><p>idealmente, deve iniciar-se ainda na fase de análise de requisitos e</p><p>modelagem do domínio, na qual o arquiteto obtém informações importantes</p><p>tanto a respeito do negócio quanto a respeito do cliente que influenciarão as</p><p>decisões arquiteturais futuras. Esse processo de definição também pode ser</p><p>subdividido em quatro fases: entendimento do problema, identificação dos</p><p>elementos do projeto e de seus relacionamentos, avaliação da arquitetura</p><p>e atualização da arquitetura.</p><p>Demos ênfase, nesta unidade, à fase de identificação dos elementos</p><p>do projeto e de seus relacionamentos, que tem no arquiteto a figura</p><p>humana central do processo. Esse papel, necessariamente, deve ser</p><p>exercido por um profissional que possua uma série de habilidades e</p><p>um perfil próprio.</p><p>A identificação dos elementos do projeto e de seus relacionamentos</p><p>passa pela representação das duas visões da arquitetura de software: a</p><p>visão estática e a visão dinâmica.</p><p>108</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade III</p><p>Na visão estática estruturamos o sistema em subsistemas e organizamos</p><p>seus componentes internos; para isso, utilizamos uma ferramenta muito</p><p>importante: os padrões.</p><p>Estilos arquiteturais e padrões de projetos são importantes soluções</p><p>para um problema específico em um contexto específico, e essas duas</p><p>variáveis são importantes nessa hora. Não devemos usar esses padrões</p><p>simplesmente por usar.</p><p>Na visão dinâmica, modelamos como os componentes e os objetos</p><p>se comunicam para resolver um determinado problema; na verdade,</p><p>nesse ponto, apenas refinamos nosso diagrama de sequência com os</p><p>conceitos de responsabilidade e organização arquitetural que vimos na</p><p>visão estática.</p><p>Ambas as visões são registradas na documentação da arquitetura a</p><p>partir de um conjunto específico de diagramas da UML.</p><p>Exercícios</p><p>Questão 1. Arquitetura de software é o nome dado à disciplina fundamental da fase de projeto</p><p>arquitetural. Dentre os benefícios de uma arquitetura de software bem definida encontram-se:</p><p>A) Facilita o reuso de componentes, logo promove maior produtividade na construção e na</p><p>manutenção, pois também facilita a manutenção.</p><p>B) Permite uma melhor análise dos requisitos funcionais durante a especificação do software.</p><p>C) Propõe um padrão de documentação, principalmente em linguagens orientadas a objetos.</p><p>D) Permite a evolução dos sistemas operacionais, SGBDs e software básico existentes.</p><p>E) Nenhuma das alternativas anteriores é correta.</p><p>Resposta correta: alternativa A.</p><p>Análise das alternativas</p><p>A) Alternativa correta.</p><p>Justificativa: dentre tantos benefícios de uma arquitetura de software bem definida, o reuso de</p><p>componentes promove a produtividade na construção, pois permite reusar componentes já construídos</p><p>e também na manutenção, já que os ajustes são realizados em poucos componentes ao invés de grandes</p><p>blocos de código.</p><p>109</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>B) Alternativa incorreta.</p><p>Justificativa: arquitetura de software não se concentra em requisitos funcionais.</p><p>C) Alternativa incorreta.</p><p>Justificativa: padrões de documentação são tratados por outras disciplinas e não por arquitetura de</p><p>software.</p><p>D) Alternativa incorreta.</p><p>Justificativa: a arquitetura de software objetiva o software a ser desenvolvido. O software básico de</p><p>apoio como Sistema Operacional, SGBD e outros não têm suas estruturas avaliadas.</p><p>Questão 2. A arquitetura de software participa das fases do ciclo de vida do projeto de software.</p><p>Com relação à fase de Pré-Projeto de software, analise as duas afirmativas apresentadas a seguir:</p><p>É comum observarmos que a arquitetura de software participa do ciclo de vida de desenvolvimento</p><p>apenas a partir da fase de projetos. No entanto, é aconselhável que o arquiteto, ou a equipe de arquitetura,</p><p>participe como observador na fase de análise de requisitos.</p><p>Porque</p><p>Essa participação possibilita a extração de informações técnicas importantes, por exemplo, padrões</p><p>de arquitetura corporativa para integração de sistemas, que podem ser importantes para mitigação de</p><p>custo, tempo de desenvolvimento e perfil da equipe.</p><p>Acerca dessas afirmativas, assinale a alternativa correta:</p><p>A) As duas afirmativas são proposições verdadeiras e a segunda é uma justificativa correta da</p><p>primeira.</p><p>B) As duas afirmativas são proposições verdadeiras e a segunda não é uma justificativa correta da</p><p>primeira.</p><p>C) A primeira afirmativa é uma proposição verdadeira e a segunda é uma proposição falsa.</p><p>D) A primeira afirmativa é uma proposição falsa e a segunda é uma proposição verdadeira.</p><p>E) As duas afirmativas são proposições falsas.</p><p>Resolução desta questão na plataforma.</p><p>110</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Unidade IV</p><p>Agora que já vimos como fazer a passagem do modelo de análise para o modelo de projeto e que</p><p>já entramos efetivamente na fase de projetos, nas atividades de projeto de dados e classes e também</p><p>nas atividades de projeto arquitetural, sabemos quais os objetivos de cada atividade e quais modelos</p><p>precisamos produzir, com o auxílio da UML.</p><p>Veremos, nesta unidade, como produzir esses modelos, representados pelos diagramas da UML, quais</p><p>são os seus elementos e como podemos utilizar cada um da melhor forma.</p><p>7 REFINANDO A MODELAGEM DE ASPECTOS DINÂMICOS DO SOFTWARE</p><p>Anteriormente, vimos que na fase de projeto arquitetural é necessária a representação dos aspectos dinâmicos</p><p>da arquitetura e, basicamente, utilizamos o diagrama de sequência da UML para dar corpo a essa representação.</p><p>O objetivo deste tópico é apresentar modelos e diagramas da UML que complementem a visão</p><p>dada pelo diagrama de sequência quando da modelagem dos aspectos dinâmicos do software.</p><p>Complementar não significa substituir, portanto nenhum diagrama que veremos a seguir tem como</p><p>objetivo substituir a visão dada pelo diagrama de sequência, mas auxiliar no refinamento da visão</p><p>arquitetural dinâmica dada por este diagrama.</p><p>7.1 Diagrama de comunicação</p><p>O diagrama de comunicação passou a ter esse nome a partir da versão 2.0 da UML; nas versões</p><p>anteriores, esse diagrama é chamado de diagrama de colaboração (UML-DIAGRAMS, 2009-2014b).</p><p>A característica marcante do diagrama de comunicação é a forte semelhança com o diagrama de</p><p>sequência. As informações modeladas em ambos são, no geral, as mesmas, todavia a representação em</p><p>cada um dos modelos possui ênfases diferentes.</p><p>O diagrama de comunicação é um tipo de diagrama comportamental da UML que representa as</p><p>interações de dois objetos e suas partes utilizando para isso uma sequência de mensagens representadas</p><p>de forma livre de formatação (UML-DIAGRAMS, 2009-2014b).</p><p>Lembrete</p><p>Embora os diagramas de comunicação e de sequência possuam grande</p><p>semelhança, o diagrama de comunicação é um complemento do diagrama</p><p>de sequência.</p><p>111</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Enquanto o diagrama de sequência dá ênfase à troca de mensagens em uma linha de tempo, o</p><p>diagrama de comunicação dá ênfase a como os objetos estão interligados e quais mensagens são</p><p>trocadas entre eles para realizar uma determinada tarefa.</p><p>No diagrama de comunicação as mensagens possuem uma numeração, é como se elas fossem</p><p>etiquetadas com uma numeração em ordem crescente, e é essa sequência numérica que representa a</p><p>sequência em que as mensagens são trocadas entre os objetos.</p><p>O diagrama de sequência obedece a uma ordem natural de leitura, ou seja, sabemos que devemos</p><p>ler a sequência das mensagens da esquerda para a direita. Enquanto isso, no diagrama de comunicação,</p><p>começamos a ler a sequência das mensagens procurando inicialmente a mensagem identificada como</p><p>1.0, seguindo essa mensagem do objeto que envia até o objeto que a recebe, e assim sucessivamente.</p><p>Podemos dizer que os diagramas de sequência e de comunicação são isomórficos, ou seja, um pode</p><p>ser transformado no outro. Isso porque os objetos, atores e mensagens que são representados nesses</p><p>diagramas são originados nos diagramas de caso de uso e nos diagramas de classes de análise e projeto,</p><p>e o que é representado no diagrama de sequência; também é representado no diagrama de comunicação</p><p>(LEE e TAPFENHART, 2001).</p><p>Observação</p><p>Existem muitas ferramentas que fazem a conversão automática do</p><p>diagrama de sequência para o diagrama de comunicação e vice-versa.</p><p>Todavia, sempre tenha muito cuidado e faça uma revisão no diagrama</p><p>gerado a partir destes tipos de ferramentas.</p><p>Quando escolher um e quando escolher o outro?</p><p>Se o seu objetivo for representar a interação dos objetos no decorrer de uma linha do tempo, então</p><p>você deverá usar o diagrama de sequência, mas se você desejar dar ênfase à interação desses objetos no</p><p>contexto do sistema, então o melhor que você terá a fazer é dar prioridade ao diagrama de comunicação</p><p>(MEDEIROS, 2004).</p><p>De qualquer forma, é importante que tenhamos em mente o principal: os diagramas são</p><p>complementares. No momento do desenvolvimento de um diagrama de comunicação a partir de um</p><p>de sequência, podemos identificar pontos de melhoria ou até mesmo erros no modelo original, daí uma</p><p>ótima oportunidade para revisar, alterar e melhorar o modelo.</p><p>Lembre-se sempre de que o objetivo dos diagramas não é produzir informação em larga quantidade,</p><p>mas produzir informação de qualidade.</p><p>Produzir um diagrama de sequência e um diagrama de comunicação com qualidade é importante</p><p>fator para a qualidade na comunicação entre os envolvidos no projeto e na qualidade da construção do</p><p>produto final.</p><p>112</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>O diagrama de comunicação é baseado em alguns componentes:</p><p>•	 Objetos:	têm	a	mesma	conotação	do	objeto	que	representamos	no	diagrama	de	sequência,	com</p><p>uma diferença fundamental, pois no diagrama de comunicação não damos ênfase à linha de</p><p>tempo de vida do objeto.</p><p>•	 Vínculos:	identificam	uma	ligação	entre	dois	objetos,	que	é	feita	a	partir	da	troca	de	mensagens</p><p>entre esses objetos.</p><p>•	 Mensagens:	análogas	às	mensagens	do	diagrama	de	sequência,	possuem	apenas	duas	diferenças</p><p>básicas: as mensagens são identificadas numericamente e não existe uma pré-formatação para</p><p>a representação dessas mensagens, como temos no diagrama de sequência. Na representação</p><p>de mensagens, podemos representar todos os tipos de mensagem — síncronas, assíncronas e</p><p>automensagem.</p><p>•	 Atores:	nesse	diagrama,	bem	como	no	diagrama	de	sequência,	podemos	representar	o	autor.	Com</p><p>o detalhe importante de que esse autor deve necessariamente estar representado também no</p><p>diagrama de caso de uso.</p><p>Cliente</p><p>2.3:[compra_encerrada] atualizar_estoque()</p><p>1.1:procurar()</p><p>1*:procurar_livros()</p><p>2:finalizar_compra()</p><p>1.2:</p><p>[livro_interessado]</p><p>vizualizar_livro()</p><p>2.1:</p><p>recuperar_livros()</p><p>1.3:</p><p>[livro_interessado]adcionarCarrinho()</p><p>2.2:[não vazio(Carrinho)]finalizar_compra()</p><p>:Estoque</p><p>:LojaOnline</p><p>:Compra</p><p>carrinho(Cliente)</p><p>CarrinhoCompras</p><p>I :LivroA</p><p>D</p><p>C</p><p>E</p><p>F</p><p>G</p><p>H</p><p>B</p><p>Figura 41 – Elementos do diagrama de comunicação UML</p><p>113</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Quadro 12 – Elementos do diagrama de comunicação UML</p><p>Letra Descrição</p><p>A Notação de ator – com o estereótipo idêntico ao visto no</p><p>diagrama de caso de uso.</p><p>B</p><p>Notação de objeto – representamos um objeto com um</p><p>retângulo, a exemplo de como representamos um objeto no</p><p>diagrama de sequência.</p><p>Podemos representar um objeto apenas como um tipo de,</p><p>como no exemplo da letra B, em que “:Estoque” lê-se um</p><p>objeto anônimo do tipo Estoque</p><p>OU</p><p>Podemos representar um objeto nominal como no exemplo</p><p>da letra G, onde “l:Livro” lê-se o objeto l do tipo Livro.</p><p>C</p><p>Representação de vínculo – a linha contínua que liga dois</p><p>objetos indica que existe um vínculo, ou uma dependência,</p><p>entre esses objetos.</p><p>Quando há um vínculo entre objetos, presume-se que haverá</p><p>troca de mensagens entre esses objetos.</p><p>D</p><p>Indicador de sequência da mensagem – no caso da figura,</p><p>temos a representação 1.*, onde podemos ler que 1 é a</p><p>sequência da mensagem e * é o número da iteração.</p><p>Ainda no exemplo da figura, podemos ver que a mensagem</p><p>inicial é a mensagem “procurar_livros()”</p><p>E</p><p>Notação de mensagem – nota-se que a representação</p><p>da mensagem é idêntica à representação de mensagem</p><p>no diagrama de sequência, ou seja: nome do método +</p><p>parâmetros de entrada + tipo de retorno.</p><p>Observação: se a mensagem for do tipo retorno, será</p><p>representada com uma seta tracejada:</p><p>F</p><p>Indicação de parâmetro da mensagem — no caso da figura,</p><p>estamos passando como</p><p>parâmetro para a mensagem</p><p>“atualizar_estoque” os livros comprados que constam na</p><p>ordem de compra.</p><p>G Declaração de objeto com nome e tipo — vide comentários</p><p>descritos na letra B.</p><p>H</p><p>Descrição de objeto com seletor e tipo — no caso da figura, o</p><p>objeto carrinho não pode ser qualquer carrinho, mas deve ser</p><p>um carrinho selecionado para um determinado cliente.</p><p>Observação: na notação de objetos, também podemos utilizar</p><p>os estereótipos de responsabilidade — entidade, fronteira e</p><p>controle —, exatamente da mesma forma que representamos</p><p>no diagrama de sequência.</p><p>Como ficaria o processo que representamos na figura anterior, utilizando o diagrama de comunicação,</p><p>se optássemos por utilizar o diagrama de sequência?</p><p>114</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>A figura a seguir mostra um diagrama de sequência análogo ao diagrama de comunicação:</p><p>Cliente</p><p>procurar_livros()</p><p>procurar()</p><p>:Estoque:LojaOnline :Compracarrinho(Cliente)</p><p>CarrinhoCompras</p><p>I :Livro</p><p>visualizarLivro(Livro)</p><p>finalizarCompra()</p><p>finalizarCompra(Carrinho)</p><p>recuperarLivrosCarrinho()</p><p>adcionarCarrinho(Livro)</p><p>Figura 42 – Exemplo de diagrama de sequência análogo ao diagrama de comunicação</p><p>A partir das figuras apresentadas podemos ter a clara noção das diferenças e semelhanças entre os</p><p>diagramas e de por que dizemos que eles são complementares.</p><p>Podemos notar também que a representação desse cenário, especificamente, utilizando o diagrama</p><p>de comunicação, projeta um diagrama que, em linhas gerais, se apresenta mais fácil de ser entendido.</p><p>Isso porque, como você pode encontrar em algumas referências, o diagrama de comunicação pode ser</p><p>utilizado para a modelagem de cenários mais simples, o que não pode ser encarado como mentira, mas</p><p>também não é uma verdade absoluta.</p><p>7.2 Diagrama de máquina de estado</p><p>O diagrama de máquina de estado, ou simplesmente diagrama de estado, tem como objetivo</p><p>representar o comportamento de um determinado elemento a partir de um conjunto finito de estados.</p><p>115</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Esse elemento a ser representado no diagrama de estado é, na maioria das vezes, uma instância</p><p>de uma classe, um objeto, uma vez que um objeto, pelos princípios da orientação a objetos, possui um</p><p>estado (LARMAN, 2007).</p><p>Note que mencionamos que na maioria das vezes utilizamos um diagrama de máquina de estados</p><p>para representar uma instância de uma classe. Isso porque podemos representar, também, a mudança</p><p>de estados de um caso de uso.</p><p>Observação</p><p>O estado de um objeto, ou a identidade desse objeto, é denominado</p><p>pelo conjunto de valores associados aos seus atributos em um determinado</p><p>período dentro do universo sistêmico.</p><p>A figura a seguir mostra a diferença entre classe, objeto e estado do objeto. Podemos notar que a</p><p>classe Cliente possui alguns atributos: agência, conta-corrente, CPF e saldo de conta-corrente.</p><p>A partir do momento em que essa classe se torna um objeto no sistema, os atributos passam a ter</p><p>um determinado valor associado e esse objeto passa a ter uma identidade única dentro do sistema,</p><p>passa a estar apto a receber e enviar mensagens, ou seja, ele passa a ser concretamente um cliente.</p><p>Classe</p><p>Atributos</p><p>Operações</p><p>Cliente</p><p>agencia: int</p><p>contaCorrente: string</p><p>cpf: string</p><p>saldoCC: decimal</p><p>informarAgenciaCC()</p><p>sacarCC()</p><p>Informar</p><p>Agência e CC</p><p>Classe</p><p>Objeto</p><p>Sacar CC</p><p>Agência: 0123</p><p>Conta-corrente: 123456-7</p><p>CPF: 999.888.777-65</p><p>Saldo de conta-corrente: R$1.000,00</p><p>Figura 43 – Classe, objeto e estado de um objeto</p><p>Já verificamos que o objeto possui um estado, por exemplo, no momento da “fotografia”, nota-se</p><p>que o cliente possui R$ 1.000,00 em sua conta-corrente. Podemos dizer então que, nesse momento, ele</p><p>possui este estado.</p><p>Em contrapartida, se este mesmo cliente, pouco tempo depois dessa “fotografia”, efetuar um saque</p><p>em conta-corrente no valor de R$ 300,00, seu estado será alterado, pois o valor do seu atributo “saldoCC”</p><p>será alterado, ou seja, haverá uma mudança de estado.</p><p>116</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>É exatamente isto que o diagrama de máquina de estado se dispõe a representar: os estados dos</p><p>objetos no decorrer do tempo e o que motivou uma possível mudança de estado. O “motivador” de uma</p><p>mudança de estado é chamado de evento.</p><p>Segundo Larman (2007), um evento é uma ocorrência digna de nota que promove a mudança de</p><p>estado de algum objeto. Como o exemplo do próprio autor: um telefone está ocioso até que é tirado do</p><p>gancho; a partir desse evento ele passa a estar ativo.</p><p>Outro exemplo simples (e aqui resumimos bem o processo, apenas para mostrar uma aplicação para</p><p>o diagrama), como mostra a figura a seguir, é o de uma máquina de autoatendimento bancário, que está</p><p>inativa até que um cartão seja inserido.</p><p>Inativo</p><p>Ativo</p><p>Inicial</p><p>[cartão removido] [cartão inserido]</p><p>Figura 44 – Diagrama de estado para um ATM</p><p>Aqui, podemos notar os elementos básicos da notação de um diagrama de estados, que estão</p><p>representados no quadro a seguir:</p><p>Quadro 13 – Elementos básicos do diagrama de estados</p><p>Símbolo Significado</p><p>Estado</p><p>Estado – representa uma determinada situação de um elemento em um</p><p>determinado momento.</p><p>Um estado pode possuir os seguintes significados:</p><p>1. A espera pela ocorrência de um evento.</p><p>2. A reação a um estímulo.</p><p>3. A execução de alguma atividade.</p><p>4. A satisfação de alguma condição.</p><p>(LARMAN, 2007)</p><p>Transição – a seta representa um evento que gera uma transição de estado</p><p>no sentido apontado.</p><p>117</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Estado inicial – representa o marco inicial, o ponto de partida da máquina</p><p>de estados.</p><p>Neste momento os objetos ainda não possuem um estado inicial, eles</p><p>passam a ter um no momento em que se inicia a máquina, ou seja, em que</p><p>a máquina sai do estado inicial.</p><p>Estado final – indica o final dos estados modelados.</p><p>O estado de um objeto pode ser classificado como:</p><p>•	 Simples:	quando	é	autossuficiente,	ou	seja,	não	possui	a	necessidade	da	composição	ou	da	divisão</p><p>em estados menores.</p><p>•	 Composto:	quando	um	estado	contém	internamente	dois	ou	mais	estados,	chamados	subestados,</p><p>como mostra o exemplo da figura seguinte:</p><p>Estado 1</p><p>Subestado 1</p><p>Subestado 2</p><p>Inicial</p><p>Figura 45 – Exemplo de estado composto</p><p>Quando um objeto entra em um determinado estado, ele executa determinadas atividades, que são:</p><p>•	 Atividade	de	entrada	(entry): é a primeira atividade a ser executada quando um objeto assume um</p><p>determinado estado.</p><p>•	 Atividades	 de	 fazer	 (do): são atividades executadas quando um objeto se encontra em um</p><p>determinado estado.</p><p>•	 Atividades	de	saída	(exit): são atividades executadas no momento em que um objeto sai de um</p><p>determinado estado.</p><p>Existem alguns tipos de transições que não produzem alteração no estado de um objeto, ou seja,</p><p>ocorrem durante o estado do objeto sem que esse estado seja modificado.</p><p>118</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Essas transições são chamadas de:</p><p>•	 Transições	 internas:	 são	 transições	 que	 acontecem	 enquanto	 um	 objeto	 se	 encontra	 em	 um</p><p>determinado estado e que não promovem modificação neste estado do objeto. Essas transições</p><p>executam atividades de fazer (do).</p><p>•	 Autotransições:	são	transições	que	executam	atividades	do	tipo	sair	(exit) de um objeto, executam</p><p>uma determinada ação e voltam para o estado de que saíram sem que haja alteração desse</p><p>estado, como mostra o exemplo a seguir:</p><p>Efetuando dispensa</p><p>de cédulas</p><p>Efetuando contagem</p><p>de cédulas</p><p>Dispensando cédulas</p><p>Inicial</p><p>Final</p><p>[notas prontas]</p><p>[contar notas]</p><p>[dispensar notas]</p><p>Figura 46 – Exemplo de autotransição</p><p>Podemos notar que, enquanto as notas não estiverem prontas na contagem, não</p><p>também,</p><p>pelo nível de eficiência no qual a solução de software atinge essas necessidades e pelo custo-benefício</p><p>do processo de desenvolvimento e construção dessa solução.</p><p>Parece-nos razoável, em um mundo onde a tecnologia de hardware evoluiu e segue em constante</p><p>evolução, que devamos nos preocupar em desenvolver sistemas de software que se adaptem às diversas</p><p>tecnologias e plataformas de computadores pessoais, sistemas operacionais, dispositivos móveis, dentre</p><p>outros. Tudo isso sem perder o foco em fornecer uma experiência rica ao usuário final, fazer que ele</p><p>tenha segurança e conforto no uso, fazer que ele possa realizar suas atividades de maneira produtiva.</p><p>Se o software deve ser enxergado como uma ferramenta de estratégia competitiva em uma</p><p>grande corporação e deve ser desenvolvido em tempo e custo de tal forma que o torne efetivamente</p><p>competitivo, não é difícil enxergar a necessidade de pensarmos em um projeto que nos possibilite</p><p>manutenção rápida e eficiente. Afinal de contas, se o mercado competitivo muda com muita rapidez,</p><p>é possível imaginar que um sistema de software também deva se adaptar a essa realidade.</p><p>Posta essa reflexão inicial, podemos nos questionar: será que realmente estamos dando a devida</p><p>importância ao processo de pensar a solução antes de simplesmente nos colocarmos em frente ao</p><p>computador e sairmos digitando linhas de código a esmo? Por que características de “outras engenharias”</p><p>como padronização, arquitetura, componentização, projeto e estabelecimento de um processo produtivo</p><p>nos parecem tão distantes da engenharia de software?</p><p>O paradigma da orientação a objetos busca oferecer um norte para as melhores práticas de</p><p>desenvolvimento de tal forma que possamos atingir, como produto final, o software como uma</p><p>ferramenta de estratégia competitiva de qualidade. Dentro do ciclo de vida de um projeto de software,</p><p>a atividade de projeto, ou design, busca organizar as soluções de projeto de tal forma que explore todo</p><p>o potencial da orientação a objetos em prol de um sistema de software de qualidade.</p><p>9</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Unidade I</p><p>1 IntrOduçãO A PrOJetO de SISteMAS</p><p>Nesta unidade iremos abordar os aspectos introdutórios que motivam a fase de projetos no paradigma</p><p>da orientação a objetos.</p><p>1.1 Por que “projetar”?</p><p>Antes de pensarmos em um projeto de software, vamos pensar em outro tipo de projeto tão comum</p><p>no nosso dia a dia: o projeto de uma casa.</p><p>Suponhamos a seguinte situação: você possui um terreno e deseja construir neste terreno uma casa.</p><p>Em um primeiro momento você mapeia tudo o que deseja que essa casa tenha, como uma lista</p><p>de desejos, ou seja, quantidade de quartos, de banheiros, área de lazer, enfim, tudo aquilo que lhe é</p><p>necessário.</p><p>Fazendo um paralelo com a engenharia de software, é como se nesse momento você tivesse a sua</p><p>lista de requisitos.</p><p>Com os seus requisitos listados você os valida, verificando se todas as suas necessidades estão</p><p>listadas e detalhadas tal qual você deseja, se a quantidade de cômodos está adequada, se a</p><p>metragem desejada para cada cômodo está detalhada e se a metragem da casa é compatível com</p><p>a metragem do terreno.</p><p>Feito isso, basta comprar os materiais e começar a construir, certo? Todos sabem que não é bem assim.</p><p>Excluindo desse cenário hipotético todos os problemas legais, é até possível que você consiga uma</p><p>casa, mas é mais provável que você enfrente muitos problemas, como os que seguem.</p><p>•	 A	casa	construída	pode	não	atender	as	suas	necessidades,	por	exemplo,	a	quantidade	de	quartos</p><p>pode até estar adequada aos seus desejos, mas a metragem não.</p><p>•	 Pode	ocorrer	de	a	casa	ficar	com	má	qualidade:	paredes	tortas,	telhado	torto,	janelas	e	portas	fora</p><p>das medidas-padrão.</p><p>•	 Podem	 ocorrer	 problemas	 na	 infraestrutura:	 por	 mau	 dimensionamento,	 as	 instalações</p><p>eletro-hidráulicas podem ficar incompletas, não funcionar como deveriam, além de oferecer risco</p><p>à estrutura da casa e a seus ocupantes.</p><p>10</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>•	 O	dinheiro	gasto	no	fim	da	obra	pode	superar	o	valor	que	você	havia	previsto	inicialmente.</p><p>•	 O	tempo	de	construção	também	pode	superar	o	tempo	previsto.</p><p>Esse é apenas um dos possíveis cenários não muito favoráveis que você poderá encontrar se não</p><p>adotar uma metodologia, ou um paradigma, para a construção da casa.</p><p>Na engenharia civil o paradigma de projeto já é mais que difundido. No caso do seu projeto, após os</p><p>seus requisitos, ou sua lista de desejos fechados, verificados e validados, a linha certa a ser adotada seria</p><p>desenvolver o projeto da sua casa.</p><p>O projeto da sua casa muito provavelmente não seria desenvolvido por você, mas sim por um</p><p>profissional ou uma equipe capaz de traduzir os seus desejos em algo mais concreto.</p><p>Por exemplo, a planta baixa da sua casa, a planta elétrica, a planta hidráulica, uma maqueta 3-D,</p><p>enfim, tudo aquilo que possa representar os seus desejos de tal forma que eles possam ser convertidos</p><p>efetivamente no produto final: a casa.</p><p>As plantas produzidas pela equipe de projeto serão utilizadas como guia para a equipe de construção,</p><p>de tal forma que os riscos associados à má qualidade da casa sejam diminuídos, ou seja, começa a</p><p>diminuir a probabilidade de problemas relacionados, por exemplo, à metragem dos cômodos, às paredes</p><p>e a todos os demais que comentamos anteriormente.</p><p>Além de servirem como um guia para a equipe de construção, as plantas, ou melhor, chamemos a</p><p>partir de agora de modelos, servem como importante instrumento de transição entre os seus requisitos</p><p>e o que será construído.</p><p>Os modelos, no projeto da sua casa, são artefatos importantes para a comunicação entre os</p><p>envolvidos no projeto, neste caso, a comunicação entre você e o projetista, e entre o projetista e a</p><p>equipe de construção.</p><p>Cada modelo é desenvolvido dirigido ao público-alvo a quem se deseja comunicar e com um objetivo</p><p>específico. Por exemplo, a planta, ou maquete da parte elétrica, possui algumas finalidades:</p><p>•	 Mostrar	para	você	e	para	a	equipe	de	construção	os	locais	corretos	onde	haverá	tomadas	e	pontos</p><p>de luz.</p><p>•	 Fornecer	subsídios	para	que	a	equipe	especializada	em	eletricidade	determine	quais	componentes</p><p>serão utilizados, de tal forma que se possa mensurar a capacidade e a segurança do sistema.</p><p>Como você pode notar, a fase de projeto, bem como os modelos produzidos nela, são fatores</p><p>fundamentais para o sucesso do projeto da sua casa.</p><p>11</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>A engenharia civil é, obviamente, muito mais antiga que a engenharia de software; se compararmos,</p><p>a engenharia de software não chega perto do que a civil evoluiu em termos de profissionais, ferramentas</p><p>e processos.</p><p>Façamos o seguinte exercício de analogia: em vez do projeto de construção de uma casa, imagine</p><p>que seu objetivo agora seja construir um sistema de software.</p><p>Inicialmente você mapeia, valida e verifica os requisitos do usuário, como você já viu nas disciplinas</p><p>anteriores.</p><p>Ainda no campo da suposição, você é um desenvolvedor, um programador habilidoso, pega os</p><p>requisitos e parte para a codificação.</p><p>A prática e a experiência mostram que os resultados para o seu produto final, o software, não fogem</p><p>muito dos resultados obtidos no projeto de construção da casa.</p><p>Um produto de má qualidade, que não atende às necessidades do usuário, que possuí problemas,</p><p>que não se adapta à infraestrutura, ou que foi desenvolvido fora dos custos e do tempo previsto, é ainda</p><p>uma realidade na indústria de software.</p><p>Em um mercado cada vez mais competitivo, problemas dessa natureza passam a ser intoleráveis. A</p><p>competitividade do software começa a trazer à tona discussões sobre outros aspectos importantes do</p><p>produto, como manutenibilidade e usabilidade.</p><p>Como construir</p><p>haverá a transição</p><p>de estado entre efetuar a dispensa e efetivamente dispensar as cédulas (BEZERRA, 2006).</p><p>No diagrama de máquina de estados, podemos ainda representar processamentos paralelos, ou seja,</p><p>quando em um determinado ponto do processo, existe uma divisão de processamentos, logo mudanças</p><p>de estados de objetos que ocorrem em paralelo.</p><p>Para representar esse paralelismo, utilizamos alguns mecanismos, como a barra de bifurcação e a</p><p>barra de união, como mostra o exemplo da figura a seguir:</p><p>Finalizando</p><p>impressão</p><p>Imprimindo folha Exibindo número</p><p>da página impressa</p><p>Inicial Bifurcação</p><p>União</p><p>Figura 47 – Exemplo de barra de bifurcação e barra de união</p><p>119</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Lembrete</p><p>Sempre que utilizarmos uma barra de bifurcação, em algum momento</p><p>do processo deveremos utilizar uma barra de união; não é possível, no</p><p>desenvolvimento de sistemas, que não haja um ponto de conversão de</p><p>processamentos paralelos.</p><p>Existe ainda a situação em que devemos representar um ponto de decisão, uma espécie de controle</p><p>do tipo if/else, um ponto em que a máquina de estado se divida em função de uma decisão.</p><p>Para essas situações, utilizamos o pseudoestado de escolha, que representa um ponto na</p><p>transição de dois estados em que deve ser tomada uma decisão, conforme mostra o exemplo da</p><p>figura seguinte:</p><p>[se valor maior que saldo e menor que limite] [se valor maior que saldo e maior que limite]</p><p>Verificando saldo</p><p>Negando saqueSolicitando</p><p>empréstimo</p><p>Efetuando saque</p><p>[se valor menor que saldo]</p><p>Figura 48 – Exemplo de pseudoestado de escolha</p><p>Além desses elementos considerados básicos, pois utilizamos com frequência em praticamente</p><p>qualquer processo que desejamos modelar, temos também os elementos considerados elementos</p><p>avançados de modelagem (GUEDES, 2009).</p><p>São eles:</p><p>•	 Pseudoestado	 de	 história:	 utilizado	 para	 representar	 o	 registro	 do	 último	 estado	 em	 que	 um</p><p>objeto se encontrava quando, por alguma razão, o processo foi interrompido. Utilizamos esse</p><p>estado para que possamos voltar o processo exatamente no ponto em que o estado se encontrava</p><p>antes de uma interrupção. Utilizamos um H para representar esse estado.</p><p>120</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Inicial</p><p>[produto adicionado]</p><p>[continuar seleção]</p><p>Adicionando carrinho</p><p>Produto adicionado</p><p>Finalizando compras</p><p>H</p><p>Figura 49 – Exemplo de pseudoestado de história</p><p>•	 Estado	de	submáquina:	utilizamos	um	estado	de	submáquina	quando	precisamos	representar	um</p><p>estado composto de alta complexidade e que, se utilizarmos apenas a representação de estado</p><p>composto, dificultará muito o entendimento em apenas um diagrama.</p><p>Inicial</p><p>Consultando pedido</p><p>Finalizando pedido</p><p>Finalizando pedido é</p><p>detalhado em outro</p><p>diagrama</p><p>Figura 50 – Exemplo de estado de submáquina</p><p>•	 Pseudoestado	de	junção:	utilizamos	esse	estado	para	representar	a	união	de	múltiplos	fluxos	em</p><p>um único ponto.</p><p>121</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>[se valor maior que saldo e menor que limite] [se valor maior que saldo e maior que limite]</p><p>Verificando saldo</p><p>Negando saqueSolicitando</p><p>empréstimo</p><p>Efetuando saque</p><p>Finalizando processo</p><p>[se valor menor que saldo]</p><p>Figura 51 – Exemplo de pseudoestado de junção</p><p>Com o diagrama de máquina de estados e com o diagrama de comunicação, fechamos a parte de</p><p>refinamento da representação dos aspectos dinâmicos da arquitetura, no projeto arquitetural.</p><p>Saiba mais</p><p>Na UML existe ainda um diagrama classificado como diagrama</p><p>comportamental, mas que é pouco utilizado atualmente, chamado</p><p>diagrama de tempo, ou de temporização. Acesse em:</p><p>UML-DIAGRAMS. Timing diagrams, 2009-2014a. Disponível em:. Acesso em: 28 abr. 2015.</p><p>8 PROJETO DE INTERFACES E PROJETO DE COMPONENTES</p><p>8.1 Projeto de interfaces</p><p>Pressman (2006, p. 222) faz uma analogia interessante sobre o que vêm a ser os componentes de um</p><p>projeto de interfaces de um sistema de software: “o projeto de interfaces é análogo a um conjunto de</p><p>desenhos detalhados de portas, janelas e ligações externas de uma casa [...] representam a maneira pela</p><p>122</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>qual as ligações de serviços públicos entram na casa e são distribuídos entre os cômodos representados</p><p>na planta”.</p><p>Os elementos do projeto de interfaces, ainda segundo Pressman (2006), representam como as</p><p>informações entram em um sistema de software e saem dele e como essas informações trafegam entre</p><p>as estruturas desse sistema definidas no projeto arquitetural.</p><p>O projeto de interface pode ser dividido em três níveis:</p><p>•	 Interfaces	internas	entre	os	componentes	do	sistema.</p><p>•	 Interfaces	externas	entre	o	sistema	e	outros	sistemas	de	software, dispositivos de hardware ou</p><p>qualquer entidade que produza ou consuma informação relevante para o sistema de software.</p><p>•	 Interface	com	o	usuário	final.</p><p>Neste tópico daremos ênfase ao projeto de interfaces internas e externas e debateremos apenas</p><p>aspectos introdutórios sobre o projeto de interface com o usuário.</p><p>8.1.1 Especificando as interfaces dos objetos</p><p>O primeiro passo para a definição das interfaces internas de um sistema, ou seja, as interfaces entre</p><p>os componentes e objetos internos de um sistema, é definirmos claramente como esses objetos estão</p><p>organizados.</p><p>Como já vimos em projeto arquitetural, agrupamos objetos que tenham alguma correlação,</p><p>geralmente, agrupamos os objetos que tenham as mesmas responsabilidades, por exemplo, no estilo</p><p>arquitetural em camadas.</p><p>Lembrete</p><p>A arquitetura em camadas pode ser entendida como “caixas”, ou</p><p>agrupamentos que são estritamente conceituais, de objetos com funções</p><p>semelhantes.</p><p>Na arquitetura em camadas, organizamos os objetos em blocos conceituais, e a comunicação</p><p>entre essas camadas se dá através de um protocolo, definido por objetos de negócio que contêm as</p><p>informações trafegadas entre essas camadas.</p><p>Podemos dizer que, ao definirmos essa camada de objetos de negócio e esse protocolo de</p><p>comunicação entre as camadas de negócio, apresentação e integração, estamos definindo uma interface</p><p>de comunicação entre esses objetos e essas camadas.</p><p>123</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Obviamente, até então, estávamos pensando nessas camadas como blocos conceituais, ou “caixas”,</p><p>para entendermos o conceito da organização arquitetural interna de um software.</p><p>Agora, iremos partir, efetivamente, para a representação desse modelo em uma linguagem de</p><p>modelagem de software. Utilizaremos, para isso, o diagrama de pacotes da UML.</p><p>8.1.2 Diagrama de pacotes</p><p>Como vimos, o processo de organização e de modelagem da solução de um sistema de software</p><p>pode envolver uma grande quantidade de objetos, classes e diagramas que podem ficar tão complexos</p><p>quanto se queira.</p><p>Ante esse cenário, é possível que você perceba a necessidade de se organizar esses componentes</p><p>em um nível de abstração um pouco maior, de tal forma que facilite o entendimento de uma visão um</p><p>pouco mais macro da solução.</p><p>Um pacote é utilizado com o propósito de agrupar logicamente objetos, entendendo-se um objeto</p><p>como qualquer elemento passível de agrupamento no processo de modelagem de um sistema: classes,</p><p>objetos, componentes e casos de uso (LARMAN, 2007).</p><p>A função principal do pacote é organizar esses objetos, esses elementos de modelagem, que possuem</p><p>semelhantes características, em agrupamentos maiores que podem ser mais facilmente entendíveis.</p><p>Como mencionado por Bezerra (2006), quando modelamos a arquitetura de uma aplicação utilizando</p><p>pacotes, podemos representar as diferentes</p><p>visões da arquitetura desse sistema, além de definirmos e</p><p>controlarmos a visibilidade dos elementos de um pacote.</p><p>A partir do momento em que definimos a visibilidade dos elementos de um pacote e a forma, ou o</p><p>protocolo, de como estes pacotes se comunicam, estamos definindo, como pano de fundo, as interfaces</p><p>dos objetos dentro do universo do sistema, também chamadas de interfaces internas.</p><p>Para representar um pacote, no diagrama de pacotes, utilizamos uma pasta com guias, como mostra</p><p>o exemplo a seguir:</p><p>Cliente</p><p>Cliente</p><p>Figura 52 – Notação de pacotes na UML</p><p>124</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Note ainda que temos duas formas de descrever o nome de um pacote: na aba do pacote, como na</p><p>notação superior, ou dentro do pacote, como na notação inferior, sendo mais comum que utilizemos a</p><p>descrição na guia da pasta.</p><p>Como um pacote é um agrupamento de elementos, podemos também utilizar um pacote como um</p><p>agrupamento de outros pacotes; nesse caso, dizemos que um pacote está contido em outro:</p><p>Cliente</p><p>Vendas</p><p>Figura 53 – Exemplo de notação de pacotes e subpacotes</p><p>No caso da figura anterior, utilizamos o nome qualificado da seguinte forma: “Cliente::Vendas”, ou</p><p>seja, no prefixo, indicamos o nome do pacote que contém o elemento.</p><p>Ainda no caso de subpacotes, podemos representar essa relação de composição, da mesma forma</p><p>que representamos composição de classes.</p><p>No caso da figura a seguir, lemos que o pacote “Cliente” é composto pelo pacote “Vendas”, ou</p><p>podemos utilizar o nome qualificado.</p><p>Cliente</p><p>Vendas</p><p>Figura 54 – Exemplo de composição de pacotes e subpacotes</p><p>Podemos utilizar pacotes para agrupar casos de uso que sejam de um contexto comum, como mostra</p><p>a figura a seguir, em que temos dois pacotes de casos de uso separados pelos seus canais de execução.</p><p>125</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Cliente</p><p>Efetuar saque</p><p>Contratar</p><p>empréstimo</p><p>Efetuar depósito</p><p>Consultar saldo</p><p>Imprimir extrato CC</p><p>Autoatendimento</p><p>Internet banking</p><p>Figura 55 – Exemplo de pacotes de caso de uso</p><p>Para representar um pacote como um agrupamento de classes, incluímos essas classes no pacote</p><p>desejado, como mostra o exemplo da figura a seguir, e nesse exemplo, também podemos utilizar a</p><p>notação de nome qualificado: “Vendas::Cliente” e “Vendas::Pedido”.</p><p>Vendas</p><p>Cliente</p><p>efetua</p><p>Pedido</p><p>Figura 56 – Exemplo de pacote de classes</p><p>Vamos nos aprofundar um pouco mais na parte mais importante do diagrama de pacotes, que é</p><p>modelar a arquitetura estática de alto nível de um sistema de software.</p><p>126</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Observação</p><p>Não confunda agrupamento lógico, que é o promovido pelo diagrama</p><p>de pacotes, com agrupamento físico de classes ou componentes. Veremos</p><p>como representar agrupamento físico adiante.</p><p>Como dissemos anteriormente, podemos definir a visibilidade de elementos dentro de um pacote.</p><p>A visibilidade dos elementos segue o mesmo conceito básico de visibilidade de atributos e métodos que</p><p>vimos nos capítulos anteriores. Temos três níveis de visibilidade: público, representado pelo sinal de positivo</p><p>(+); privado, representado pelo sinal de negativo (-); e protegido, representado pelo sinal sustenido (#), com</p><p>algumas diferenças exploradas no contexto de pacotes, como se explica a seguir:</p><p>Vendas</p><p>+ Cliente</p><p>- Pedido</p><p># ItemPedido</p><p>Figura 57 – Exemplo de visibilidade de elementos de um pacote</p><p>Na figura anterior, temos um pacote com três classes: “Cliente”, “Pedido” e “ItemPedido”; seus</p><p>respectivos níveis de visibilidade estão descritos na representação da própria classe.</p><p>Nesse caso, fazemos as seguintes leituras:</p><p>•	 Um	elemento	marcado	como	público	 (+)	 é	 visível	por	 todos	os	outros	pacotes	do	 sistema.	As</p><p>partes públicas desse pacote constituem a interface desse pacote.</p><p>•	 Um	elemento	marcado	como	privado	(-)	é	visível	somente	por	outros	elementos	do	mesmo	pacote.</p><p>Elementos privados não podem ser vistos por outros pacotes.</p><p>•	 Um	elemento	marcado	como	protegido	(#)	é	visível	somente	em	pacotes-filhos	do	pacote	ao	qual</p><p>pertence. Um pacote-filho é um pacote que possui relação de herança com outro pacote.</p><p>Já que tocamos no assunto herança de pacotes, vejamos quais são os tipos de relacionamento</p><p>possíveis entre pacotes e como podemos representá-los no diagrama.</p><p>Podemos dizer que um pacote X dependerá de um pacote Y se um elemento, ou um objeto qualquer</p><p>de X, depender de outro elemento ou objeto qualquer de Y (BEZERRA, 2006).</p><p>127</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>É importante que se diga que, a partir do momento em que criamos dependência entre pacotes,</p><p>uma alteração no pacote de destino afeta diretamente o pacote dependente. Observe alguns tipos de</p><p>dependências (MEDEIROS, 2004):</p><p>Dependência simples é quando um elemento de um pacote possui alguma relação com um</p><p>elemento de outro pacote. Como mostra o exemplo da figura a seguir, que é a representação, em</p><p>pacotes, da arquitetura em camadas que vimos anteriormente. Neste caso, podemos afirmar que</p><p>classes do pacote de interface do usuário possuem ligação com classes do pacote de negócios, e</p><p>assim sucessivamente.</p><p>Interface com o Usuário</p><p>Camada de Negócios</p><p>Camada de Integração</p><p>Objetos de Negócios</p><p>Figura 58 – Exemplo de dependência simples de pacotes</p><p>Dependência com estereótipo de acesso é quando o pacote dependente é incorporado aos</p><p>elementos públicos do pacote de destino.</p><p>Dependência com estereótipo de importação é quando os elementos públicos do pacote de</p><p>destino são adicionados ao pacote dependente, como mostra a figura a seguir:</p><p>128</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Pagamento</p><p>Cliente</p><p>></p><p>> ></p><p>Carrinho de compras</p><p>Item</p><p>Figura 59 – Exemplo de dependência estereotipada de pacotes</p><p>Herança aplicada a pacotes possui o mesmo conceito utilizado em herança do paradigma da</p><p>orientação a objetos. Utilizamos herança de pacotes quando desejamos representar generalização ou</p><p>especialização de famílias de pacotes. O exemplo, representado pela figura a seguir, mostra pacotes com</p><p>classes específicas para desenho de formulários de sistemas desktop, ou baseado em janelas.</p><p>Nesse caso, temos num pacote-mãe, todos os objetos responsáveis pelo desenho de janelas genéricas,</p><p>e, nos pacotes-filhos, temos as especializações, para desenho de janelas em sistemas operacionais dos</p><p>tipos Windows, Linux e Mac.</p><p>Linux User Interface Window</p><p>User Interface Window</p><p>Windows User Interface Window Mac User Interface Window</p><p>Figura 60 – Exemplo de herança de pacotes</p><p>129</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Saiba mais</p><p>A implementação de “pacotes” na linguagem da plataforma Microsoft</p><p>.Net corresponde ao conceito de namespace. Para aprofundar seus</p><p>conhecimentos sobre o tema, leia:</p><p>CAMARA, F. Orientação a objeto com .NET. 2. ed. Santa Catarina: Visual</p><p>Books, 2006.</p><p>Assim como “pacotes” corresponde ao conceito de package da linguagem</p><p>Java, como se vê em:</p><p>SIERRA, K; BATES, B. Use a Cabeça! Java. 2. ed. Rio de Janeiro: Alta</p><p>Books, 2007.</p><p>8.1.3 Introdução ao projeto de interfaces com o usuário</p><p>O projeto de interfaces com o usuário está ligado diretamente ao fator usabilidade. Abordaremos</p><p>aspectos introdutórios e que são muito importantes para o sucesso do projeto de software.</p><p>Dentro de um modelo de atributos de qualidade de software, de acordo com a ISO 25010 (2011a),</p><p>a usabilidade encaixa-se entre os seis principais que delimitam a qualidade de um produto, que são:</p><p>confiabilidade, funcionalidade, eficiência, manutenibilidade, portabilidade e usabilidade.</p><p>Usabilidade</p><p>está ligada ao projeto, à avaliação e à implementação de sistemas computacionais,</p><p>contemplando hardware e software, de tal forma que ajude os usuários em suas tarefas, em um contexto</p><p>específico, de maneira produtiva (ISO, 2011a; ROCHA; BARANAUSKAS, 2003).</p><p>Engenharia de usabilidade é o nome dado ao conjunto de atividades distribuídas na forma estruturada</p><p>de projeto de sistemas computacionais cujo objetivo é a usabilidade (ROCHA; BARANAUSKAS, 2003).</p><p>Mayhew (1999), outra referência quando falamos sobre usabilidade, também define engenharia da</p><p>usabilidade como uma disciplina que visa fornecer técnicas, processos e ferramentas que possam servir</p><p>de suporte a um projeto de um sistema computacional com ênfase no usuário.</p><p>O principal objetivo da engenharia da usabilidade, qualquer que seja o modelo adotado, é a</p><p>diminuição do custo no desenvolvimento de um projeto centrado no usuário através da redução</p><p>nos tempos de desenvolvimento, treinamento e retrabalho (ROCHA; BARANAUSKAS, 2003;</p><p>NIELSEN, 1993).</p><p>É importante mencionar que engenharia de usabilidade não está ligada apenas a atividades,</p><p>processos e técnicas, mas também à filosofia de considerar o usuário como centro do processo, levando</p><p>130</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>em consideração o ambiente e aspectos cognitivos e psicológicos na execução de sua rotina (AVELINO,</p><p>2005; MAYHEW, 1999; NIELSEN, 1993).</p><p>Como podemos notar, o projeto de interface do usuário está ligado à engenharia da usabilidade,</p><p>que deve ser tratada com muito mais aprofundamento do que simplesmente desenharmos interfaces</p><p>do usuário.</p><p>Shneiderman (1998), por exemplo, aponta como um dos fatores fundamentais de sucesso para</p><p>um sistema computacional interativo, a preocupação com aspectos inerentes às atividades do usuário,</p><p>como sua capacidade perceptiva e sua habilidade cognitiva na execução de suas tarefas diárias.</p><p>A usabilidade não tem recebido a atenção necessária na fase de elaboração da arquitetura de um</p><p>sistema computacional, fato este que pode levar ao retrabalho tardio, bem como tornar o sistema</p><p>menos usável do que poderia ser (GOLDEN; JOHN; BASS, 2005).</p><p>Saiba mais</p><p>Para aprofundar seus conhecimentos sobre a preocupação com a</p><p>usabilidade	 e	 os	 aspectos	 que	 influenciam	 o	 projeto	 de	 um	 sistema	 de</p><p>software, leia:</p><p>GOLDEN, E.; JOHN, B. E.; BASS, L. The value of a usability-supporting</p><p>architectural pattern in software architecture design: a controlled</p><p>experiment. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING</p><p>– ICSE, 2005, St. Louis. Proceedings... St. Louis: ICSE, 2005.</p><p>8.2 Projeto de componentes</p><p>Antes de pensarmos em como projetar componentes, precisamos ter muito claro o que é um</p><p>componente, bem como quais os objetivos e os benefícios em se componentizar um software.</p><p>8.2.1 Introdução à componentização e ao reúso de software</p><p>A componentização, ou o desenvolvimento componentizado de software, é um paradigma, tal qual</p><p>o paradigma da orientação a objetos, que não se limita apenas ao desenvolvimento de componentes,</p><p>assim como a orientação não se limita a classes a esmo.</p><p>Analogamente ao paradigma da orientação a objetos, que define um guia, uma forma de se</p><p>desenvolver software, cujo fundamento é o conceito de objetos, a componentização tem como base o</p><p>conceito de componentes.</p><p>131</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Os cinco princípios básicos de um componente, segundo Cheesman e Daniels (2000), uma das</p><p>melhores referências no assunto, são:</p><p>•	 Um	componente	obrigatoriamente	deve	possuir	uma	especificação.</p><p>•	 Um	componente	obrigatoriamente	deve	possuir	uma	implementação.</p><p>•	 Um	componente	obrigatoriamente	deve	seguir	uma	padronização.</p><p>•	 Um	componente	obrigatoriamente	deve	ter	a	capacidade	de	ser	empacotado	em	módulos.</p><p>•	 Um	componente	obrigatoriamente	deve	ter	a	capacidade	de	ser	distribuído.</p><p>Um componente de software é como um componente de um sistema eletrônico, uma unidade</p><p>projetada e construída para possuir seus próprios processamento, regras e informações.</p><p>Essa unidade pode ser substituída, por qualquer motivo (erro ou evolução), por outra unidade com</p><p>as mesmas características de relação para com o restante do sistema, sem que haja dano ou modificação</p><p>no funcionamento do todo.</p><p>Nesta disciplina, não conseguiremos abordar todo o paradigma da componentização, mas veremos</p><p>os aspectos introdutórios fundamentais que fazem a conexão entre o paradigma da orientação a objetos</p><p>e o da componentização.</p><p>Um componente de software se dispõe a prestar um serviço para o restante do sistema; por princípio,</p><p>ele deve ser consistente e conciso com relação às suas responsabilidades, de tal forma que atinja baixo</p><p>acoplamento e alta coesão.</p><p>Lembrete</p><p>Os conceitos de acoplamento e coesão de componentes são os mesmos</p><p>que aplicamos quando debatemos acoplamento e coesão de classes</p><p>anteriormente.</p><p>Esse serviço prestado pelo componente deve ser visível a outros componentes (clientes) que,</p><p>porventura, desejem acessar esse serviço. Analogamente ao paradigma da orientação a objetos, é como</p><p>se cada componente possuísse um método público que pudesse ser chamado por outros componentes.</p><p>Podemos dizer que entre o componente que disponibiliza o serviço e o componente que consome</p><p>esse serviço existe um contrato, uma regra que não pode ser quebrada por nenhuma das partes.</p><p>Para o componente que consome o serviço, é indiferente como o componente implementa ou qual a</p><p>lógica interna que é utilizada para resolver um determinado problema; o importante é que o protocolo</p><p>de comunicação seja mantido.</p><p>132</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>A interface de um componente é análoga à que temos no paradigma da orientação a objetos, ou</p><p>seja, é um contrato que determina o que deve ser feito, mas que não estipula como deve ser feito.</p><p>Essa padronização do protocolo de comunicação entre os componentes e entre os objetos nos</p><p>garante uma alta capacidade de reúso do componente que oferece um determinado serviço; se um</p><p>componente quiser utilizar um determinado serviço, bastará adaptar-se a esse protocolo, sem que haja</p><p>necessidade de alteração no componente fornecedor.</p><p>Os paradigmas da componentização e da orientação a objetos se cruzam em um ponto, na medida</p><p>em que podemos considerar que um componente é uma estrutura de software composta por objetos,</p><p>que, quando compilados, geram estruturas físicas e concisas que podem ser encaradas como um sistema</p><p>computacional, por exemplo, bibliotecas (dlls), executáveis (exes), tabelas, documentos etc.</p><p>Observação</p><p>Componentes e pacotes são semelhantes quanto à função de</p><p>agrupamento, todavia diferem com relação ao final desse agrupamento:</p><p>componentes são agrupamentos físicos de objetos, enquanto pacotes são</p><p>meramente agrupamentos lógicos.</p><p>Se temos serviços definidos por interfaces e implementados por classes, podemos dizer que essas</p><p>interfaces podem ser externas ou exportadoras de serviços desses sistemas de software.</p><p>Saiba mais</p><p>Para aprofundar seus conhecimentos sobre o assunto, leia:</p><p>CHEESMAN, J.; DANIELS, J. UML components: a simple process for</p><p>specifying component-based software. Addison-Wesley, 2000.</p><p>GIMENES, I. M. S.; HUZITA, E. H. M. Desenvolvimento baseado em</p><p>componentes: conceitos e técnicas. Rio de Janeiro: Ciência Moderna, 2005.</p><p>8.2.2 Definindo as interfaces externas</p><p>As interfaces externas ao componente, ou ao sistema de software, são determinadas pelas suas</p><p>interfaces, que definem o protocolo, ou o contrato de comunicação entre objetos consumidores e</p><p>provedores de serviço.</p><p>Essa relação de consumo de serviços acaba por criar uma dependência entre esses componentes ou</p><p>entre objetos. As dependências podem ser classificadas como simples ou estereotipadas.</p><p>133</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>:</p><p>F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Observação</p><p>A relação de dependência entre componentes e objetos, nesse contexto,</p><p>é considerada fraca, uma vez que o consumidor depende apenas da</p><p>interface, e não da implementação do fornecedor do serviço.</p><p>Dependências simples são dependências entre componentes delimitadas pela interface, por</p><p>exemplo, uma dependência entre um executável e uma DLL, enquanto dependências estereotipadas são</p><p>dependências particulares de um determinado cenário, por exemplo, dependências entre páginas de um</p><p>web site, que podem ser marcadas como >.</p><p>Para representação e modelagem de componentes e de suas interfaces, utilizaremos o diagrama de</p><p>componentes da UML.</p><p>8.2.3 Diagrama de componentes</p><p>No diagrama de componentes da UML utilizamos, para representação de componentes, uma caixa</p><p>com tabs, como mostra o exemplo da figura a seguir. Ainda na figura, podemos notar a identificação do</p><p>nome do componente.</p><p>kernel32.dll</p><p>Figura 61 – Exemplo de notação de componentes</p><p>Podemos ainda utilizar a estereotipação para identificar o tipo do componente, como mostra o</p><p>exemplo da figura a seguir:</p><p>></p><p>Nome do executável</p><p>></p><p>Nome da dll</p><p>Figura 62 – Exemplo de representação de componentes com estereotipação</p><p>134</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>O quadro seguinte mostra os possíveis tipos de estereotipação para componentes e seus respectivos</p><p>significados.</p><p>Quadro 14 – Tipos de componentes e estereotipação</p><p>Estereótipo Tipo de componente</p><p>> Componente que pode ser executado.</p><p>> Biblioteca, que pode ser estática ou dinâmica.</p><p>> Banco de dados.</p><p>> Tabela de um banco de dados.</p><p>> Documento.</p><p>> Arquivo, que pode ser desde um arquivo que possui</p><p>apenas informações a um arquivo com código-fonte.</p><p>A representação de interface de componentes, no diagrama da UML, é feita como mostra a</p><p>figura a seguir. Nessa figura, podemos ler que o componente DLL possui uma interface que é</p><p>consumida pelo executável; o conector convexo indica a interface, e o conector côncavo indica</p><p>o consumidor.</p><p>></p><p>Nome do executável</p><p>></p><p>Nome do executável</p><p>></p><p>Nome da dll</p><p>></p><p>Nome da dll</p><p>></p><p>Interface</p><p>Dependência</p><p>Implementação</p><p>Figura 63 – Exemplo de conexão e de dependência entre componentes</p><p>Essa é a representação de dependências simples entre componentes, ou seja, quando há a conexão</p><p>feita a partir de interfaces. A figura a seguir mostra um exemplo de dependência estereotipada.</p><p>135</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>></p><p>Index.html</p><p>></p><p>Cliente.html</p><p>></p><p>Figura 64 – Exemplo de representação de dependência estereotipada</p><p>Lembrete</p><p>Pacotes são agrupamentos lógicos de elementos, que podem ser</p><p>classes ou casos de uso, como vimos anteriormente; ou podemos</p><p>utilizar pacotes para agrupar logicamente componentes que possuam</p><p>funções semelhantes.</p><p>O diagrama de componentes representa uma visão mais física do sistema de software; as partes</p><p>desse sistema são apresentadas sob uma perspectiva mais concreta, ou seja, podemos empacotar esses</p><p>componentes e distribuí-los.</p><p>Contudo, esse diagrama não nos dá a visão da organização desses componentes sob o enfoque da</p><p>organização da estrutura física sobre a qual o software será implantado e executado.</p><p>Pensando em estrutura física, podemos imaginar que iremos distribuir esses componentes em</p><p>diversas plataformas, ou que, eventualmente, parte do nosso sistema de software será executada</p><p>em uma plataforma, um sistema operacional, enquanto outra parte poderá ser executada em outra</p><p>plataforma, ou em outro tipo de sistema operacional.</p><p>Como representar, modelar e especificar essas questões importantes e que nem sempre têm</p><p>a atenção devida? O diagrama de distribuição ou de implantação auxilia-nos nesse primeiro</p><p>momento.</p><p>8.2.4 Diagrama de distribuição</p><p>O diagrama de distribuição, ou de implantação, mostra como os componentes são configurados para</p><p>execução, em “nós” de processamento (LARMAN, 2007).</p><p>136</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Um “nó” de processamento é um recurso computacional que permite a execução de um sistema de</p><p>software, ou de parte dele, como um componente. Esse “nó” pode ser um computador, um dispositivo</p><p>móvel ou até mesmo uma estrutura de memória ou um dispositivo periférico.</p><p>No diagrama de implantação, utilizamos um cubo para representar um “nó”, que “nó” deve possuir</p><p>um nome e um tipo, como mostra a figura a seguir:</p><p>PC</p><p>Figura 65 – Exemplo de representação de nó do tipo computador do usuário</p><p>Com a visão que nos é fornecida pelo diagrama de implantação, podemos visualizar as dependências</p><p>entre os “nós” e como se dá a comunicação entre esses “nós”.</p><p>Por exemplo, em um sistema cliente-servidor, teremos dois “nós”: o cliente e o servidor.</p><p>Com o diagrama, poderemos deixar clara a dependência entre esses dois “nós”, além de especificar</p><p>o protocolo de comunicação entre esses “nós”, por exemplo, se será uma comunicação via HTTP ou</p><p>HTTPS. Esses detalhes são fundamentais para o dimensionamento da infraestrutura necessária ao</p><p>sistema de software.</p><p>Neste diagrama podemos representar os componentes contidos em cada “nó”, como mostra o</p><p>exemplo da figura a seguir:</p><p>Servidor</p><p>Servidor de Banco de Dados</p><p>PC</p><p>></p><p>Navegador web</p><p>></p><p>e-commerce</p><p>Base de dados SQL</p><p>TCP/IP</p><p>HTTP</p><p>Figura 66 – Exemplo de distribuição de componentes em nós</p><p>137</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Resumo</p><p>Nesta unidade demos ênfase a como produzir os modelos referentes</p><p>às fases de projeto arquitetural, projeto de interfaces e projeto de</p><p>componentes, uma vez que, na unidade anterior, vimos onde, quais e</p><p>quando esses modelos seriam utilizados.</p><p>Começamos o debate desta unidade explanando que refinar os</p><p>aspectos dinâmicos da arquitetura de um sistema de software significa</p><p>complementar a visão dada pelo diagrama de sequência, e não substituí-lo.</p><p>O objetivo desse refinamento se dá pela necessidade de prover uma</p><p>melhor qualidade da informação que é passada pela equipe de construção</p><p>e pelos demais envolvidos no projeto, pois quantidade de informação, como</p><p>vimos, não necessariamente quer dizer melhor qualidade.</p><p>Para complementar a visão do diagrama de sequência, vimos,</p><p>inicialmente, o diagrama de comunicação, que, nas versões anteriores da</p><p>UML, era chamado de diagrama de colaboração.</p><p>Este diagrama, assim como o de sequência, tem característica</p><p>comportamental, ou seja, visa à modelagem das interações dos objetos,</p><p>mas, diferentemente do diagrama de sequência, não dá ênfase à troca de</p><p>mensagens em uma linha de tempo, mas à interligação e à dependência</p><p>dos objetos.</p><p>Temos, no diagrama de colaboração, três elementos principais de</p><p>modelagem: o objeto, os vínculos entre eles e as mensagens trocadas,</p><p>que são etiquetadas em ordem numérica e crescente para que possamos</p><p>visualizar a sequência em que elas são executadas.</p><p>Vimos que os diagramas de sequência e colaboração são análogos, ou</p><p>seja, as informações contidas em um, obrigatoriamente, aparecem no outro;</p><p>a diferença fica apenas no enfoque de cada diagrama. No entanto, deve-se</p><p>ficar atento para ferramentas que promovem a conversão automática dos</p><p>diagramas.</p><p>O último diagrama a complementar a visão comportamental da</p><p>arquitetura é o diagrama de máquina de estado, ou diagrama de estado,</p><p>cujo objetivo é representar as mudanças de estado de um objeto no decorrer</p><p>do tempo.</p><p>138</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>O estado de um objeto é dado pelo conjunto de valores de seus</p><p>atributos, que pode ser modificado por um evento do sistema. Esse</p><p>evento promove uma transição de estado do objeto, e esse processo</p><p>é objeto de representação desse diagrama a partir de uma máquina</p><p>finita de estados.</p><p>Além dos elementos básicos de modelagem: estado/transição e</p><p>todos os tipos de mensagens presentes no diagrama de sequência, o</p><p>diagrama de estado provê mecanismos avançados de representação de</p><p>fluxos alternativos, paralelos, além de mecanismos para facilitação da</p><p>representação de estados mais complexos, por exemplo, o pseudoestado</p><p>de história, o estado composto e o estado de submáquina.</p><p>Avançando para o projeto de interfaces, vimos que essa fase pode ser</p><p>dividida em três níveis: projeto de interfaces internas, externas e interface</p><p>com o usuário final.</p><p>O projeto de interfaces internas dá ênfase a como os objetos internos</p><p>do sistema de software se comunicam, e para representar a organização</p><p>lógica desses componentes utilizamos o diagrama de pacotes, pois o</p><p>primeiro passo para a definição do protocolo de comunicação é estabelecer</p><p>quais objetos possuem interfaces com quais objetos.</p><p>O pacote é um mecanismo de organização lógica de elementos de</p><p>modelagem; esses elementos podem ser: os casos de uso, as classes e</p><p>os componentes.</p><p>O projeto de interface com o usuário envolve a engenharia da usabilidade,</p><p>que é a área de estudo preocupada em fazer o usuário executar as tarefas</p><p>do dia a dia de forma produtiva.</p><p>O projeto de componentes é um assunto profundo e ligado intimamente</p><p>ao paradigma da componentização, que cruza com o paradigma da</p><p>orientação a objetos.</p><p>Um componente obrigatoriamente deve possuir: especificação,</p><p>implantação, padronização e capacidade de ser empacotado e distribuído.</p><p>Um componente de software é uma unidade autônoma e suficiente,</p><p>que objetiva baixo acoplamento e alta coesão e promove o reúso. Esse</p><p>componente é formado por objetos.</p><p>Cada componente é um provedor de serviços, e esses serviços são</p><p>definidos por interfaces, que são contratos que determinam quais</p><p>139</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>serviços são fornecidos e qual é o protocolo de comunicação entre</p><p>o cliente e o fornecedor, sem se preocupar com o modo pelo qual</p><p>esses serviços serão implementados.</p><p>Para modelar os componentes de um sistema, utilizamos o diagrama</p><p>de componentes da UML, sempre lembrando que o mais importante é a</p><p>definição clara das dependências entre os componentes, dadas a partir das</p><p>interfaces.</p><p>No diagrama de distribuição representamos em que lugar, dentro de</p><p>uma infraestrutura, esses componentes serão distribuídos. A importância</p><p>desse diagrama se dá pela visão que temos para mensurar a infraestrutura</p><p>necessária para o sucesso do projeto.</p><p>Exercícios</p><p>Questão 1. Um componente de software é como um componente de um sistema eletrônico, uma</p><p>unidade projetada e construída para possuir seu próprio processamento, regras e informações.</p><p>Com base nos cinco princípios básicos de um componente, segundo Cheesman e Daniels (2001),</p><p>analise as afirmativas a seguir:</p><p>I – Um componente obrigatoriamente deve possuir uma especificação em UML.</p><p>II – Um componente obrigatoriamente deve possuir uma implementação.</p><p>III – Um componente opcionalmente deve seguir uma padronização.</p><p>IV – Um componente obrigatoriamente deve ter a capacidade de ser empacotado em módulos.</p><p>V – Um componente obrigatoriamente deve ter a capacidade de ser distribuído.</p><p>É correto apenas o que se afirma em:</p><p>A) I e II.</p><p>B) II e IV.</p><p>C) I, II, III e IV.</p><p>D) II, IV e V.</p><p>E) I, II, e IV.</p><p>Resposta correta: alternativa D.</p><p>140</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade IV</p><p>Análise das afirmativas</p><p>I – Afirmativa incorreta.</p><p>Justificativa: não há menção da obrigatoriedade da linguagem UML para a especificação do</p><p>componente na descrição dos cinco princípios básicos de um componente, segundo Cheesman e Daniels</p><p>(2001).</p><p>II – Afirmativa correta.</p><p>Justificativa: um componente obrigatoriamente deve possuir uma implementação.</p><p>III – Afirmativa incorreta.</p><p>Justificativa: um componente deve obrigatoriamente, e não opcionalmente, seguir uma</p><p>padronização.</p><p>IV – Afirmativa correta.</p><p>Justificativa: um componente obrigatoriamente deve ter a capacidade de ser empacotado em</p><p>módulos.</p><p>V – Afirmativa correta.</p><p>Justificativa: um componente obrigatoriamente deve ter a capacidade de ser distribuído.</p><p>Questão 2. O diagrama de comunicação é um tipo de diagrama de comportamental da UML,</p><p>que representa as interações entre dois objetos e suas partes utilizando para isso uma sequência de</p><p>mensagens representadas de forma livre de formatação (UML Diagrams, 2015).</p><p>De acordo com os conceitos do diagrama de comunicação, analise as duas afirmativas apresentadas</p><p>a seguir:</p><p>O diagrama de comunicação dá ênfase em como os objetos estão interligados e quais mensagens</p><p>são trocadas entre eles para realizar uma determinada tarefa.</p><p>Porque</p><p>No diagrama de comunicação, as mensagens possuem uma numeração, é como se elas fossem</p><p>“etiquetadas” com uma numeração, em ordem crescente, e é essa sequência numérica que representa a</p><p>sequência nas quais as mensagens são trocadas entre os objetos.</p><p>Acerca dessas afirmativas, assinale a alternativa correta:</p><p>141</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>A) As duas afirmativas são proposições verdadeiras e a segunda é uma justificativa correta da</p><p>primeira.</p><p>B) As duas afirmativas são proposições verdadeiras e a segunda não é uma justificativa correta da</p><p>primeira.</p><p>C) A primeira afirmativa é uma proposição verdadeira e a segunda é uma proposição falsa.</p><p>D) A primeira afirmativa é uma proposição falsa e a segunda é uma proposição verdadeira.</p><p>E) As duas afirmativas são proposições falsas.</p><p>Resolução desta questão na plataforma.</p><p>142</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>FIGURAS E ILUSTRAçõES</p><p>Figura 1</p><p>SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2010. p. 30. Adaptado.</p><p>Figura 4</p><p>PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: Mcgraw-hill, 2006. p. 208. Adaptado.</p><p>Figura 8</p><p>MEDEIROS, L. F. Banco de dados: princípios e prática. Curitiba: InterSaberes, 2013. Adaptado.</p><p>Figura 9</p><p>SAXENA, V.; PRATAP, A. Performance comparison between relational and object-oriented databases.</p><p>International Journal of Computer Applications, p. 6-9, 2013. Adaptado.</p><p>Figura 10</p><p>BEZERRA, E. Princípios de análise e projeto de sistemas com UML: um guia prático para modelagem de</p><p>sistemas orientados a objetos através da linguagem de modelagem unificada. Rio de Janeiro: Campus,</p><p>2006. p. 168. Adaptado.</p><p>Figura 11</p><p>BEZERRA, E. Princípios de análise e projeto de sistemas com UML: um guia prático para modelagem de</p><p>sistemas orientados a objetos através da linguagem de modelagem unificada. Rio de Janeiro: Campus,</p><p>2006. p. 168. Adaptado.</p><p>Figura 12</p><p>BEZERRA, E. Princípios de análise e projeto de sistemas com UML: um guia prático para modelagem de</p><p>sistemas orientados a objetos através da linguagem de modelagem unificada. Rio de Janeiro: Campus,</p><p>2006. p. 168. Adaptado.</p><p>Figura 17</p><p>BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006. p.</p><p>258. Adaptado.</p><p>143</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Figura 18</p><p>BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006.</p><p>p. 258. Adaptado.</p><p>Figura 19</p><p>ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo: Addison-Wesley, 2011. p.</p><p>133. Adaptado.</p><p>Figura 30</p><p>MERSON, P. How to represent the architecture of your application using UML 2.0 and more. Pitsburgo:</p><p>Software Engineering Institute, 2006. Adaptado.</p><p>Figura 39</p><p>TIAKO, P. F. Software applications: concepts, methodologies,</p><p>tools, and applications. 1. ed. Langston:</p><p>Information Science Reference, 2009. p. 597. Adaptado.</p><p>Figura 41</p><p>UML-DIAGRAMS. UML communication diagrams overview, 2009-2014. Disponível em: . Acesso em: 27 abr. 2015. Adaptado.</p><p>Figura 52</p><p>LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e</p><p>ao processo unificado. 2. ed. Porto Alegre: Bookman, 2007. Adaptado.</p><p>Figura 53</p><p>LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e</p><p>ao processo unificado. 2. ed. Porto Alegre: Bookman, 2007. Adaptado.</p><p>Figura 56</p><p>LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e</p><p>ao processo unificado. 2. ed. Porto Alegre: Bookman, 2007. Adaptado.</p><p>Figura 59</p><p>UML-DIAGRAMS. UML package diagrams overview, 2009-2014. Disponível em:. Acesso em: 28 abr. 2015. Adaptado.</p><p>144</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Figura 66</p><p>LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e</p><p>ao processo unificado. 2. ed. Porto Alegre: Bookman, 2007. p. 585. Adaptado.</p><p>REFERêNCIAS</p><p>Textuais</p><p>ACOPLAMENTO. In: Michaelis: moderno dicionário da língua portuguesa. São Paulo: Companhia</p><p>Melhoramentos, 1998.</p><p>ALBIN, S. T. The art of software architecture: design methods and techniques. Indianapolis: John Wiley, 2003.</p><p>ARQUITETURA. In: Michaelis: moderno dicionário da língua portuguesa. São Paulo: Companhia</p><p>Melhoramentos, 1998.</p><p>AVELINO, V. F. Merusa: metodologia de especificação de requisitos de usabilidade e segurança</p><p>orientada para arquitetura. 2005. Tese (Doutorado em Engenharia) – Escola Politécnica da</p><p>Universidade de São Paulo, São Paulo, 2005.</p><p>BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice. Boston: Addison-Wesley, 2010.</p><p>BEZERRA, E. Princípios de análise e projeto de sistemas com UML: um guia prático para modelagem</p><p>de sistemas orientados a objetos através da linguagem de modelagem unificada. Rio de Janeiro:</p><p>Campus, 2006.</p><p>BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006.</p><p>BROOKS, F. No silver bullet: essence and accidents of software engineering. Computer, v. 20, n. 4, p.</p><p>10-9, 1987.</p><p>BUSCHMANN, F. et al. Pattern-oriented software architecture: a system of patterns. New York: Wiley,</p><p>1996. v. 1.</p><p>BUSCHMANN, F.; HENNEY, K.; SCHIMIDT, D. Pattern-oriented software architecture: a pattern language</p><p>for distributed computing. New York: Wiley, 2007. v. 4.</p><p>CAMARA, F. Orientação a objeto com .NET. 2. ed. Santa Catarina: Visual Books, 2006.</p><p>CATTELL, R. G. et al. The object data management standard: ODMG 3.0. California: Morgan Kaufmann, 2000.</p><p>CHEESMAN, J.; DANIELS, J. UML components: a simple process for specifying component-based</p><p>software. Addison-Wesley, 2000.</p><p>145</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>CHIAVENATO, I. Os novos paradigmas: como as mudanças estão mexendo com as empresas. Barueri:</p><p>Manole, 2008.</p><p>COAD, P.; YOURDON, E. Projetos baseados em objetos. Rio de Janeiro: Campus, 1993.</p><p>COESO. In: Michaelis: moderno dicionário da língua portuguesa. São Paulo: Companhia</p><p>Melhoramentos, 1998.</p><p>CORTÊS, M. L.; CHIOSSI, T. C. S. Modelos de qualidade de software. Campinas: Unicamp, 2001.</p><p>COSTA, I. et al. Qualidade em Tecnologia da Informação. São Paulo. Atlas, 2013.</p><p>COUTAZ, J. PAC, an object oriented model for dialog design. In: HUMAN-COMPUTER INTERACTION</p><p>– INTERAC’ 87, 1987, Stuttgart. Proceedings... Stuttgart: Elsevier Science Publishers, 1987. p. 431-6.</p><p>Disponível em: . Acesso em: 24 abr. 2015.</p><p>DOFACTORY. .NET design pattern framework 4.5, [s.d.]. Disponível em: . Acesso em: 4 maio 2015.</p><p>DRIVER, M. Java and .NET: you can’t pick a favorite child. In: DEVELOPER SUMMIT, 2007, Palm Springs.</p><p>Proceedings... Palm Springs, 2007. Disponível em: . Acesso em: 22 abr. 2015.</p><p>ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo: Addison-Wesley, 2011.</p><p>FREEMAN, E et al. Head first design patterns. Sebastopol: O’Reilly, 2004.</p><p>GAMMA, E. et al. Design patterns: elements of reusable object-oriented software. Boston: Addison-</p><p>Wesley, 1995.</p><p>GIMENES, I. M. S.; HUZITA, E. H. M. Desenvolvimento baseado em componentes: conceitos e técnicas.</p><p>Rio de Janeiro: Ciência Moderna, 2005.</p><p>GOLDEN, E.; JOHN, B. E.; BASS, L. The value of a usability-supporting architectural pattern in software</p><p>architecture design: a controlled experiment. In: INTERNATIONAL CONFERENCE ON SOFTWARE</p><p>ENGINEERING – ICSE, 2005, St. Louis. Proceedings... St. Louis: ICSE, 2005.</p><p>GUEDES, G. T. A. UML 2: uma abordagem prática. São Paulo: Novatec, 2009.</p><p>GUERRA, A. C.; COLOMBO, R. M. T. Tecnologia da informação: qualidade de produto de software.</p><p>Brasília: PBQP, 2009.</p><p>HEINEMAN G. T.; COUNCILL, W. T. Component-based software engineering: putting the pieces</p><p>together. Boston: Addison-Wesley Longman Publishing, 2001.</p><p>146</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>HUANG, R. Making active CASE tools: toward the next generation CASE tools. Software Engineering</p><p>Notes, v. 23, p. 47-50, janeiro, 1998.</p><p>INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). ISO 10746-3: open distributed</p><p>processing – Reference model. Geneve: ISO, 2009.</p><p>___. ISO 25010: systems and software engineering – Systems and software quality requirements and</p><p>evaluation (square) – system and software quality models. Geneve: ISO, 2011a.</p><p>___. ISO 42010: systems and software engineering – Architecture description. Geneve: ISO, 2011b.</p><p>KRUCHTEN, P. The 4+1 view model of architecture. IEEE Software, Washington, v. 12, n. 6, p. 42-50,</p><p>nov. 1995.</p><p>LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e</p><p>ao processo unificado. 2. ed. Porto Alegre: Bookman, 2007.</p><p>LEE, R. C; TAPFENHART, W. M. UML e C++: guia prático de desenvolvimento orientado a objeto. São</p><p>Paulo: Makron Books, 2001.</p><p>MAGDY, A. et al. Flexible CASE Tools for Requirements Engineering: A benchmarking Survey. Cairo, p.</p><p>20-6, 2008.</p><p>MAHDY. A. A. E-R.; AHMED, M. M. A. E-S.; ZAHRAN, S. M. Flexible CASE tools for requirements</p><p>engineering: a benchmarking survey. In: INTERNATIONAL CONFERENCE OF INFORMATICS AND</p><p>SYSTEMS, 2008. Proceedings... Cairo, 2008. Disponível em: . Acesso em: 17 abr. 2015.</p><p>MARTINS, C. T. K.; RODRIGUES, M. Algoritmos elementares C++. São Paulo: LCTE, 2006.</p><p>MAYHEW, D. J. The usability engineering lifecycle: a practitioner’s handbook for user interface design.</p><p>São Francisco: Morgan Kaufmann, 1999.</p><p>MCGLAUGHLIN, R. Some Notes on Program Design, Software Engineering Notes, v. 16, n. 4, p. 53-4, Oct. 1991.</p><p>MEDEIROS, L. F. Banco de dados: princípios e prática. Curitiba: InterSaberes, 2013.</p><p>MEDEIROS, S. E. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Makron Books, 2004.</p><p>MERSON, P. How to represent the architecture of your application using UML 2.0 and more. Pitsburgo:</p><p>Software Engineering Institute, 2006.</p><p>MICHAELIS. Moderno dicionário da língua portuguesa. São Paulo: Melhoramentos, 1998.</p><p>NIELSEN, J. Usability engineering. São Francisco: Morgan Kaufmann, 1993.</p><p>147</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>OBJECT MANAGEMENT ARCHITECTURE. Object Management Group, 2014. Disponível em: . Acesso em: 17 abr. 2015.</p><p>OBJECT MANAGEMENT GROUP (OMG). Corba basics, 2015. Disponível em: . Acesso em: 5 maio 2015.</p><p>OPENUP. Introduction to OpenUP.</p><p>[s.d.]a. Disponível em: . Acesso em: 4 maio 2015.</p><p>___. Role: analyst, [s.d.]c. Disponível em: . Acesso em: 4 maio 2015.</p><p>___. Role: architect, [s.d.]b. Disponível em: . Acesso em: 4 maio 2015.</p><p>___. Role: stakeholder, [s.d.]d. Disponível em: . Acesso em: 4 maio 2015.</p><p>PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.</p><p>PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.</p><p>ROCHA, H. V.; BARANAUSKAS, M. C. C. Design e avaliação de interfaces humano-computador.</p><p>Campinas: Instituto de Computação da Universidade Estadual de Campinas, 2003.</p><p>SAXENA, V.; PRATAP, A. Performance comparison between relational and object-oriented databases.</p><p>International Journal of Computer Applications, p. 6-9, 2013.</p><p>SHNEIDERMAN, B. Designing the user interface: strategies for effective human-computer interaction.</p><p>3. ed. Menlo Park: Addison-Wesley, 1998.</p><p>SIERRA, K; BATES, B. Use a Cabeça! Java. 2. ed. Rio de Janeiro: Alta Books, 2007.</p><p>SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 5. ed. Rio de Janeiro:</p><p>Campus, 2006.</p><p>SOFTWARE ENGINEERING INSTITUTE (SEI). Architecture tradeoff analysis method, 2015a. Disponível</p><p>em: . Acesso em: 4 maio 2015.</p><p>___. Defining software architecture, 2015b. Disponível em: .</p><p>Acesso em: 4 maio 2015.</p><p>SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2010.</p><p>148</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>STADZISZ, P. C. Projeto de software usando a UML. Paraná: UTFPR, 2002.</p><p>SZYPERSKI, C. Component software: beyond object-oriented programming. 2. ed. Boston: Addison-</p><p>Wesley Longman, 2002.</p><p>THE HISTORY OF SMALLTALK. Smalltalk.org, 2010. Disponível em: . Acesso em: 17 abr. 2015.</p><p>TIMING DIAGRAMS. UML Diagrams, 2009-2014. Disponível em:. Acesso em: 28 abr. 2015.</p><p>TIAKO, P. F. Software applications: concepts, methodologies, tools, and applications. Langston:</p><p>Information Science Reference, 2009.</p><p>TSUDA, M. et al. Productivity analysis of software development with an integrated CASE tool. In:</p><p>INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 14., 1992, Melbourne. Proceedings...</p><p>Melbourne: ICSE, 1992.</p><p>UML-DIAGRAMS. Timing diagrams, 2009-2014a. Disponível em:. Acesso em: 28 abr. 2015.</p><p>___. UML 2.5 Diagrams Overview, 2009-2014b. Disponível em:. Acesso em: 28 abr. 2015.</p><p>VERSOLATTO, F. R. Uma abordagem arquitetural aplicada ao ciclo de vida da Engenharia da Usabilidade</p><p>em prontuário eletrônico de pacientes. 2012. Dissertação (Mestrado em Engenharia de Software) –</p><p>Instituto de Pesquisas Tecnológicas de São Paulo (IPT), São Paulo, 2012.</p><p>Sites</p><p>.</p><p>.</p><p>.</p><p>.</p><p>.</p><p>.</p><p>.</p><p>.</p><p>.</p><p>.</p><p>149</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>150</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>151</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>152</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Informações:</p><p>www.sepi.unip.br ou 0800 010 9000</p><p>o software de tal forma que atenda aos requisitos do usuário de forma eficaz e que,</p><p>ainda assim, seja sustentável e competitivo? Uma das respostas pode estar no paradigma da projetização.</p><p>2 O PrOJetO nO CICLO de VIdA dA enGenHArIA de SOFtwAre</p><p>2.1 A fase de projetos</p><p>Como você deve lembrar, na engenharia de software temos alguns modelos de processo de</p><p>desenvolvimento.</p><p>Observação</p><p>O processo de desenvolvimento de software resume-se a um conjunto</p><p>de atividades executadas em uma determinada sequência. Esse conjunto de</p><p>atividades também pode ser chamado de etapas da engenharia de software</p><p>ou paradigmas da engenharia de software (PRESSMAN, 2006).</p><p>Muitos são os modelos de processos aplicados e debatidos atualmente. Para exemplificar, vamos</p><p>trabalhar com um dos modelos mais tradicionais: o Modelo Cascata.</p><p>12</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>Também chamado de waterfall ou também citado na literatura como ciclo de vida clássico, o Modelo</p><p>Cascata é composto de cinco atividades:</p><p>•	 Análise	de	requisitos.</p><p>•	 Projeto.</p><p>•	 Codificação.</p><p>•	 Testes.</p><p>•	 Implantação	e	manutenção.</p><p>Análise de</p><p>requisitos</p><p>Projeto</p><p>Codificação</p><p>Testes</p><p>Implantação e</p><p>manutenção</p><p>Figura 1 – Sequência de execução das atividades no Modelo Cascata</p><p>No Modelo Cascata, as atividades são executadas de forma sequencial. Assim, uma atividade não é</p><p>iniciada até que sua predecessora seja completamente finalizada. Isso nos permite afirmar, por exemplo,</p><p>que a construção não é iniciada até que seja finalizada a arquitetura do sistema de software na fase de</p><p>projeto, que, por sua vez, não é iniciada até que todos os requisitos sejam levantados, documentados e</p><p>aprovados pelo usuário.</p><p>A fase de projeto não se inicia até que todos os requisitos sejam elicitados, documentados e aprovados</p><p>pelo usuário. É comum que requisitos novos surjam e sejam alterados no curso do projeto, pelas mais</p><p>diversas razões, dentre elas a falta de habilidade do analista em extrair e captar as necessidades do</p><p>processo de negócio. A mudança nos requisitos pode ocorrer durante a fase de projeto, codificação</p><p>ou até mesmo na fase de testes, assim como problemas na arquitetura podem ser identificados na</p><p>construção ou na implantação.</p><p>13</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Saiba mais</p><p>Existem ainda outros modelos, como o Modelo Incremental, o Modelo</p><p>Espiral e o Processo Unificado. Para aprofundar seus conhecimentos sobre</p><p>o assunto, leia:</p><p>PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw Hill,</p><p>2006.</p><p>SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2010.</p><p>Independentemente do modelo de ciclo de vida que adotarmos, peguemos como exemplo o Modelo</p><p>Cascata. A fase de projetos encontra-se sempre na fronteira entre a análise de requisitos, o problema e</p><p>a construção, ou implementação.</p><p>A fase de projetos sempre se inicia após a fase de requisitos, ou após uma primeira iteração dos</p><p>requisitos, nos casos em que adotamos um modelo de ciclo de vida iterativo incremental ou qualquer</p><p>variante dele.</p><p>Observação</p><p>A diferença fundamental entre os modelos clássico, cascata e iterativo:</p><p>no modelo incremental não é necessário que todos os requisitos estejam</p><p>mapeados para se iniciar o ciclo de desenvolvimento.</p><p>Logo, enquanto não tivermos os requisitos, ou parte deles, elicitados, verificados e validados, não se</p><p>inicia a fase de projeto. Isso significa dizer que, uma vez iniciada a fase de projetos, os requisitos não</p><p>poderão ser alterados?</p><p>A resposta é não, pois os requisitos sempre poderão ser alterados, inclusive, é comum que isso</p><p>aconteça; no entanto, uma vez que haja necessidade de alteração dos requisitos após a fase de projetos</p><p>ser iniciada, os impactos deverão ser mapeados e mensurados, e as devidas alterações no projeto deverão</p><p>ser feitas.</p><p>Podemos dizer que a fase de projeto dentro do ciclo de vida da engenharia de software é a</p><p>fronteira entre o domínio do problema e o domínio da solução. Como Pressman (2006, p. 206)</p><p>cita, “o modelo de requisitos dá ênfase no o que precisa ser feito, enquanto o modelo de projeto</p><p>indica o como será feito”.</p><p>14</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>Observação</p><p>Na literatura a terminologia indicativa de projeto em inglês é design.</p><p>Não se confunda com project.</p><p>2.2 Por que modelar?</p><p>Voltemos ao nosso exemplo do projeto de construção de uma casa. A planta baixa da casa é a</p><p>representação de uma visão da casa, podemos considerar que ela é um modelo que representa a casa.</p><p>Este modelo pode ser utilizado tanto para você validar se todas as suas necessidades serão</p><p>efetivamente construídas quanto para ser um guia para a equipe de construção.</p><p>Imaginemos que, em uma situação hipotética, você não tenha gostado de algo da planta; o projetista,</p><p>por alguma razão, não conseguiu captar suas necessidades, ou até mesmo você mudou de ideia com</p><p>relação a alguma necessidade.</p><p>Diante dessa situação, basta alterar a planta, ou o modelo, e validá-lo novamente. Os esforços</p><p>seriam muito maiores se tivéssemos de alterar a construção, em vez do modelo.</p><p>Na fase de projeto, os modelos de projeto têm como objetivo representar as diversas visões da</p><p>solução de um sistema de software.</p><p>Assim como a planta da casa, esses modelos têm como objetivo representar como os requisitos serão</p><p>atendidos, antecipam possíveis alterações que possam ser feitas quando do momento da construção</p><p>(codificação), antecipando, assim, alguns dos riscos do projeto.</p><p>Modelos são como guia para a construção e são insumos fundamentais para a validação da qualidade</p><p>do software. Trataremos com mais detalhes a seguir.</p><p>Saiba mais</p><p>A discussão sobre o processo de qualidade é ampla. Leia:</p><p>COSTA, I. et al. Qualidade em tecnologia da informação. São Paulo:</p><p>Atlas, 2013.</p><p>É na fase de projeto, também, que incorporamos elementos de tecnologia para a solução, como no</p><p>exemplo da casa, quando falamos sobre os componentes de uma planta elétrica.</p><p>15</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Nesse caso, modelos são úteis para que possamos mensurar a infraestrutura necessária e efetuar</p><p>provas de conceito de possíveis soluções que possamos adotar, sempre, antes do momento da construção.</p><p>Observação</p><p>O objetivo central deste livro-texto é discutir a fase de projetos de um</p><p>sistema de software que, por sua vez, tem ênfase em como serão resolvidos</p><p>os problemas e as necessidades do negócio que são levantadas na fase</p><p>de análise. É importante ter em mente que, em qualquer modelo de ciclo</p><p>de vida, antes da fase de projeto, temos a fase de análise, que, dentre</p><p>outras atividades, compreende a engenharia e análise dos requisitos e dos</p><p>problemas a serrem resolvidos pelo sistema de software.</p><p>2.3 Conceitos do projeto</p><p>Em seu livro, Pressman (2006, p. 212), enumera uma série de conceitos básicos de projeto que</p><p>“fornecem a organização necessária para estruturá-lo e fazer com que funcione corretamente”.</p><p>Observação</p><p>Roger Pressman e Iam Sommerville são considerados dois dos maiores</p><p>expoentes da Engenharia de Software.</p><p>Abstração e modularidade são dois dos principais conceitos apresentados por Pressman (2006).</p><p>2.3.1 Abstração</p><p>O projeto deve, por finalidade, possuir vários níveis de abstração. Nos níveis mais altos de abstração</p><p>do software nos aproximamos do nível de análise, enquanto nos níveis mais baixos nos aproximamos</p><p>da solução técnica do software.</p><p>Observação</p><p>O conceito de abstração está ligado a nossa capacidade, enquanto</p><p>analistas, de resolver problemas, de selecionar determinados aspectos do</p><p>problema e de isolar o que é importante do que não é, para um determinado</p><p>propósito. Abstração é dar ênfase àquilo que é essencial.</p><p>No começo do projeto é importante darmos ênfase a soluções macro,</p><p>e à medida que o projeto for</p><p>avançando, vamos descendo ao nosso nível de solução, ou de abstração.</p><p>16</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>2.3.2 Modularidade</p><p>O software deve ser dividido em componentes, ou módulos, que trabalham em conjunto para</p><p>desempenhar uma determinada atividade e atingir um determinado objetivo.</p><p>O grande desafio da modularidade está em equilibrar as responsabilidades de cada componente, de</p><p>tal forma que não haja uma superdependência ou a sobrecarga de um único componente.</p><p>O que se deseja atingir com a modularidade é: baixo acoplamento e alta coesão. Para entender a</p><p>questão, veja a figura a seguir.</p><p>A</p><p>B</p><p>D</p><p>C</p><p>E</p><p>Figura 2 – Exemplo de dependência entre módulos</p><p>Imagine que o sistema tenha cinco módulos: A, B, C, D e E. Como indicado pelas setas, na figura</p><p>anterior, temos as seguintes relações de dependência:</p><p>•	 “B”	depende	funcionalmente	de	“A”.</p><p>•	 “C”	depende	funcionalmente	de	“A”.</p><p>•	 “D”	depende	funcionalmente	de	“A”.</p><p>•	 “E”	depende	funcionalmente	de	“A”.</p><p>Uma característica marcante dessa estrutura, e que pode ser facilmente notada, é uma alta</p><p>dependência do módulo A. Por exemplo, em uma situação hipotética de falha ou de algum tipo de</p><p>manutenção no módulo A, todos os demais módulos seriam afetados diretamente, comprometendo,</p><p>assim, todo o sistema.</p><p>No caso hipotético desse sistema, dizemos que ele tem um alto acoplamento e uma baixa coesão.</p><p>A definição do dicionário Michaelis (1998) para acoplamento que mais se aproxima do cenário de</p><p>software é: “união de dois circuitos, com a finalidade de transferir energia de um para outro”.</p><p>17</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>No nosso caso, acoplamento está relacionado à união de dois componentes, todavia com a finalidade</p><p>de transferir informações de um para outro.</p><p>O mesmo dicionário (MICHAELIS, 1998) define coeso como algo “firmemente unido ou ligado”.</p><p>Para software indicamos e buscamos uma alta coesão que sempre se dá pelo baixo acoplamento, ou</p><p>seja, o ideal é o inverso do que se mostra na figura anterior.</p><p>A</p><p>B C</p><p>Figura 3 – Exemplo de dependência entre módulos</p><p>O mesmo efeito da Figura 2 pode ser notado na Figura 3, na qual temos três módulos: A, B e C, e com</p><p>o relacionamento indicado pelas setas podemos chegar às seguintes conclusões:</p><p>•	 “A”	depende	funcionalmente	de	“B”	e	“C”.</p><p>•	 “B”	depende	funcionalmente	de	“A”	e	“C”.</p><p>Assim como na Figura 2, uma característica marcante dessa estrutura é a alta dependência em relação ao</p><p>módulo C. Uma falha ou algum tipo de manutenção no módulo C e todos os demais módulos seriam afetados</p><p>diretamente, comprometendo, assim, todo o sistema. Todavia existe algo ainda mais marcante nessa estrutura:</p><p>uma dependência circular, o que igualmente provoca alto acoplamento e baixa coesão.</p><p>Nem sempre é fácil enxergar esses problemas no momento em que estamos pensando na solução do</p><p>projeto, e, para isso, Pressman (2006), cita outros conceitos fundamentais de projeto, todos associados</p><p>diretamente ou indiretamente a esses problemas, que são:</p><p>•	 Divisão	por	interesses:	indica	que	um	problema	complexo	pode	ser	mais	facilmente	resolvido	se</p><p>for dividido em pequenas partes ou pequenos problemas.</p><p>•	 Encapsulamento	de	informações:	significa	dizer	que	os	módulos	devem	ser	projetados	de	uma</p><p>forma tal que as informações e sua lógica interna não sejam visíveis por outros módulos, a não</p><p>ser que seja necessário. Em resumo, é deixar visível apenas o necessário.</p><p>Lembrete</p><p>Encapsulamento é um dos conceitos fundamentais da orientação a</p><p>objetos, assim como: classe, objeto, abstração, herança e polimorfismo.</p><p>18</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>•	 Independência	 funcional:	 é	 uma	 das	 balizas	 fundamentais	 quando	 estamos	 querendo	 atingir</p><p>acoplamento e coesão. Independência funcional está associada a projetar módulos que tenham</p><p>funções bem-definidas, minimizando a dependência em relação a outros módulos. Em resumo, é</p><p>dizer que um módulo não deve fazer mais nem menos.</p><p>2.4 Fases de projeto</p><p>Como debatemos anteriormente, o objetivo da fase de projetos é solucionar tecnicamente, ou dar</p><p>solução, aos requisitos do usuário mapeados no modelo de requisitos.</p><p>As fases, ou subdivisão das atividades, da fase de projeto estão associadas ao que efetivamente deve</p><p>ser produzido como artefato na fase de projeto. Pressman (2006) divide o modelo de projetos em quatro</p><p>fases:</p><p>•	 Projeto	de	componentes.</p><p>•	 Projeto	de	interfaces.</p><p>•	 Projeto	arquitetural.</p><p>•	 Projeto	de	dados/classes.</p><p>Conforme mostra a figura a seguir:</p><p>Projeto de</p><p>componentes</p><p>Projeto de interfaces</p><p>Projeto arquitetural</p><p>Projeto de dados/classes</p><p>Modelo de requisitos</p><p>Figura 4 – Fases do modelo de projeto</p><p>19</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>A figura anterior mostra a sequência de atividades e o fluxo das informações da fase de projeto.</p><p>•	 Projeto	 de	 dados/classes:	 essa	 fase,	 que	 tem	 como	 insumo	 o	 modelo	 de	 requisitos	 (casos	 de</p><p>uso, descrição de casos de uso, modelo de classe conceitual etc.), tem como objetivo a geração</p><p>do modelo de dados e a transformação de classes e objetos conceituais em classes e objetos</p><p>equivalentes em projeto.</p><p>•	 Projeto	arquitetural:	organiza	as	classes	e	objetos	em	componentes	do	software e define seus</p><p>relacionamentos.</p><p>Observação</p><p>A discussão sobre arquitetura de software é mais ampla do que a simples</p><p>organização de componentes e dos seus relacionamentos, como mostra o</p><p>livro de Bass, Clements e Kazman (2010). Trataremos do assunto com mais</p><p>profundidade nas próximas unidades.</p><p>•	 Projeto	 de	 interfaces:	 descreve	 todas	 as	 possíveis	 interfaces	 de	 um	 sistema,	 que	 podem	 ser:</p><p>interfaces internas (como a comunicação entre os componentes será organizada), interfaces</p><p>externas (comunicação do sistema com outros sistemas) e interfaces com o usuário.</p><p>Saiba mais</p><p>O projeto de interface com o usuário envolve muitos aspectos e vem</p><p>sendo considerado cada vez mais como uma disciplina apartada chamada</p><p>usabilidade, como é possível verificar em:</p><p>NIELSEN, J. Usability engineering. San Francisco: Morgan Kaufmann,</p><p>1993.</p><p>VERSOLATTO, F. R. Uma abordagem arquitetural aplicada ao ciclo de</p><p>vida da Engenharia da Usabilidade em prontuário eletrônico de pacientes.</p><p>2012. Dissertação (Mestrado em Engenharia de Software) — Instituto de</p><p>Pesquisas Tecnológicas de São Paulo (IPT), São Paulo, 2012.</p><p>•	 Projeto	de	componentes:	a	partir	do	modelo	desenhado	no	projeto	de	arquitetura,	 refina-os	e</p><p>detalha-os de tal forma que seja possível a descrição procedimental desses componentes.</p><p>Neste livro-texto, trabalharemos com os artefatos produzidos em cada fase de projeto da metodologia</p><p>proposta por Pressman (2006), porém polarizado para o paradigma da orientação a objetos.</p><p>20</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>2.5 Aspectos humanos da fase de projetos</p><p>Conforme vimos nas disciplinas anteriores, em todos os modelos de ciclo de vida, uma fase é</p><p>composta por uma série de atividades, que produzem um determinado número de artefatos.</p><p>Estas atividades, além de produzirem algum resultado, são executadas por pessoas, ou papéis.</p><p>Lembrete</p><p>Um papel pode ser desempenhado por mais de uma pessoa, assim como</p><p>uma pessoa pode desempenhar diferentes papéis ao longo do ciclo de vida</p><p>do projeto.</p><p>Nesta seção iremos mapear os papéis envolvidos, diretamente ou indiretamente, na atividade de</p><p>projeto, baseado no processo unificado especificado no OpenUP (OPENUP, [s.d.]a).</p><p>São eles:</p><p>Arquiteto</p><p>Quadro 1 – Atividades e habilidades do arquiteto no OpenUP</p><p>Atividades</p><p>•	Conduz	ou	coordena	o	projeto	técnico	do	sistema	e	tem	a	responsabilidade	pelas</p><p>decisões técnicas.</p><p>•	Identifica	e	documenta	os	aspectos	significativos	para	a	arquitetura	do	sistema	como</p><p>visões que descrevem requisitos, projeto, implementação e implantação.</p><p>•	Justifica	as	soluções	técnicas	equilibrando	os	interesses	das	várias	partes	envolvidas,</p><p>reduzindo os riscos e garantindo que essas soluções sejam comunicadas, validadas e</p><p>principalmente seguidas pela equipe de construção.</p><p>•	Trabalha	junto	com	gerentes	de	projeto,	recursos	humanos	e	planejamento	do	projeto;	o</p><p>processo recomenda que a equipe seja organizada em torno da arquitetura.</p><p>•	Trabalha	junto	com	os	analistas	e	desenvolvedores	para	garantir	que	o	guia	da</p><p>arquitetura seja seguido.</p><p>Habilidades</p><p>•	Experiência	nos	domínios	do	problema	e	da	engenharia	de	software.</p><p>•	Habilidade	de	liderança.</p><p>•	Habilidade	de	comunicação.</p><p>•	Habilidade	de	análise	crítica,	principalmente,	para	garantir	que	o	desenvolvimento	não</p><p>fuja da arquitetura definida.</p><p>•	Proatividade	com	ênfase	nos	objetivos	e	nos	resultados.</p><p>Adaptado de: OpenUP ([s.d.]b).</p><p>21</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Analista</p><p>Quadro 2 – Atividades e habilidades do analista no OpenUP</p><p>Atividades</p><p>•	Identifica	e	detalha	os	requisitos.</p><p>•	Descreve	os	casos	de	uso.</p><p>•	Auxilia	no	desenvolvimento	da	visão	técnica,	fornecendo	os	subsídios	necessários.</p><p>Habilidades</p><p>•	Experiência	na	identificação	de	problemas	e	soluções.</p><p>•	Capacidade	de	articular	as	necessidades	que	são	associadas	com	o	problema-chave</p><p>a ser resolvido.</p><p>•	Capacidade	de	colaborar	efetivamente	com	a	equipe	a	partir	de	sessões</p><p>colaborativas de trabalho.</p><p>•	Capacidade	de	comunicação	verbal	e	escrita.</p><p>•	Conhecimento	dos	domínios	de	negócios	e	de	tecnologia	ou	a	capacidade	de</p><p>absorver e compreender essas informações rapidamente.</p><p>Adaptado de: OPENUP ([s.d.]c).</p><p>Gerente de projetos</p><p>Quadro 3 – Atividades e habilidades do gerente de projetos no OpenUP</p><p>Atividades</p><p>•	Liderança	da	equipe	para	um	bom	resultado	e	da	aceitação	do	produto	por	parte	do</p><p>cliente.</p><p>•	É	responsável	pelo	resultado	do	projeto	e	da	aceitação	do	produto	por	parte	do</p><p>cliente.</p><p>•	É	responsável	pela	avaliação	dos	riscos	do	projeto	e	por	controlar	esses	riscos	por</p><p>meio de estratégias de mitigação.</p><p>•	Aplica-se	o	conhecimento	de	gestão,	habilidades,	ferramentas	e	técnicas	para	uma</p><p>ampla gama de tarefas para entregar o resultado desejado para um determinado</p><p>projeto em tempo hábil.</p><p>Habilidades</p><p>•	Capacidades	de	liderança	e	formação	de	equipes.</p><p>•	Experiência	completa	do	ciclo	de	vida	de	desenvolvimento	de	software para treinar,</p><p>orientar e apoiar outros membros da equipe.</p><p>•	Proficiência	em	resolução	de	conflitos	e	técnicas	de	resolução	de	problemas.</p><p>•	Bons	conhecimentos	em	apresentação,	facilitação,	comunicação	e	negociação.</p><p>Adaptado de: OpenUP ([s.d.]d).</p><p>Além desses três papéis, envolvidos com a fase de projeto, existem os stakeholders, que são, segundo</p><p>o OpenUP ([s.d.]c), grupos de interesse, cujas necessidades devem ser satisfeitas pelo projeto. É um papel</p><p>que pode ser desempenhado por qualquer pessoa que é (ou potencialmente será) afetada pelo resultado</p><p>do projeto.</p><p>Um papel secundário na fase de projetos, uma vez que sua ênfase de atuação é na fase de construção,</p><p>é o do desenvolvedor, que na fase de projetos participa em duas frentes: entendimento da arquitetura</p><p>e sugestão de soluções técnicas.</p><p>22</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>Saiba mais</p><p>O OpenUP é uma variante de processo unificado que determina um</p><p>modelo de ciclo de vida iterativo e incremental. Para aprofundar seus</p><p>conhecimentos, acesse:</p><p>.</p><p>2.6 O que buscamos atingir no projeto?</p><p>Pressman (2006), citando McGlaughlin (1991), coloca três metas fundamentais da fase de projeto:</p><p>•	 O	projeto	deve	contemplar	a	implementação	de	todos	os	requisitos	explícitos,	e	aí	uma	observação</p><p>importante e que muitas vezes é deixada de lado, o projeto deve acomodar, ou deixar apto a</p><p>receber, todos os requisitos implícitos.</p><p>•	 O	projeto	deve	ser	um	guia	para	desenvolvedores,	testadores	e	para	aqueles	de	darão	suporte	ao</p><p>software.</p><p>•	 O	projeto	deve	fornecer	uma	visão	completa	do	software sempre tendo como norte o aspecto</p><p>implementação (MCGLAUGHLIN, 1991, p. 209 apud PRESSMAN, 2006).</p><p>Lembrete</p><p>Na Engenharia de Requisitos não é tão incomum um requisito não ser</p><p>mapeado, ou ser mapeado incompletamente. Isso pode ser devido a uma</p><p>série de fatores, dentre eles, por exemplo, uma falha de comunicação entre</p><p>o analista de requisitos e o usuário.</p><p>Além desses três pontos enumerados por Pressman (2006), a norma ISO 25010 (ISO, 2011a) trata</p><p>da classificação e da definição de requisitos não funcionais, mas que também definem um modelo de</p><p>qualidade utilizado como referência para a avaliação de qualidade de software.</p><p>Observação</p><p>O International Organization for Standardization (ISO) é um grupo</p><p>fundado em 1947, sem relações com órgãos governamentais, localizado na</p><p>cidade de Genebra, na Suíça, com o objetivo de definir diretrizes normativas.</p><p>A norma descreve seis características que definem a qualidade de software: funcionalidade, confiabilidade,</p><p>usabilidade, eficiência, manutenibilidade e portabilidade. Essas características, também denominadas atributos</p><p>de qualidade, são comumente usadas quando trabalhamos com requisitos não funcionais.</p><p>23</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>O quadro a seguir mostra a definição dos atributos de qualidade de acordo com a ISO 25010.</p><p>Quadro 4 – Atributos de qualidade segundo a ISO 25010</p><p>Atributo Descrição</p><p>Funcionalidade</p><p>Está ligado à capacidade do sistema de software de prover funcionalidades</p><p>que atendam às necessidades explícitas e implícitas quando usado sob as</p><p>condições especificadas.</p><p>Confiabilidade Está ligado à capacidade do sistema de software de manter um determinado</p><p>nível de desempenho quando usado sob as condições especificadas.</p><p>Usabilidade</p><p>Está ligado à capacidade do sistema de software de auxiliar os usuários na</p><p>realização de suas tarefas, de maneira produtiva (ROCHA; BARANAUSKAS,</p><p>2003).</p><p>Eficiência Está ligado à capacidade do sistema de software de prover desempenho</p><p>apropriado, relativo à quantidade de recursos utilizados.</p><p>Manutenibilidade Está ligado à capacidade do sistema de software de ser modificado, e essa</p><p>modificação pode ser uma correção, melhoria ou adaptação.</p><p>Portabilidade Está ligado à capacidade do sistema de software de ser portável entre</p><p>plataformas de ambientes.</p><p>Adaptado de: ISO (2011a, p.16-21).</p><p>A figura a seguir mostra a estrutura hierárquica dos atributos de qualidade, quanto à sua classificação,</p><p>proposta pela norma ISO 25010 (ISO, 2011a).</p><p>Funcionalidade</p><p>Adequação, acurácia,</p><p>interoperabilidade, segurança</p><p>de acesso e conformidade</p><p>Usabilidade Inteligibilidade, facilidade no</p><p>aprendizado e operacionalidade</p><p>Manutenibilidade Facilidade de análise, alteração,</p><p>estabilização e teste</p><p>Confiabilidade Maturidade, tolerância a falhas</p><p>e facilidade na recuperação</p><p>Eficiência Comportamento em relação ao</p><p>tempo e utilização de recursos</p><p>Portabilidade</p><p>Adaptabilidade, capacidade</p><p>para ser instalado, coexistência,</p><p>capacidade para substituir</p><p>Atributos de</p><p>qualidade</p><p>Figura 5 – Requisitos não funcionais, segundo a classificação da ISO 25010</p><p>24</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>Conforme ilustrado, os seis atributos de qualidade – funcionalidade, confiabilidade, usabilidade,</p><p>eficiência, manutenibilidade e portabilidade – também possuem uma estratificação para outros atributos</p><p>de qualidade, conforme citado também por Cortês e Chiossi (2001).</p><p>•	 Funcionalidade</p><p>— Adequação: é a garantia de que o software possui as funções que foram definidas.</p><p>— Acurácia: está relacionada ao grau de precisão dos resultados gerados pelo software.</p><p>— Interoperabilidade: é a capacidade do software de interagir com outros sistemas.</p><p>— Segurança de acesso: está ligada à capacidade do software de prevenir acessos por pessoas ou</p><p>aplicações não autorizadas.</p><p>— Conformidade: se o software foi desenvolvido seguindo os padrões, convenções ou regras</p><p>preestabelecidas no projeto.</p><p>•	 Confiabilidade</p><p>— Maturidade: está relacionada à baixa frequência de falhas ou defeitos do software em operação.</p><p>— Tolerância a falhas: está relacionada a um determinado nível de desempenho que o software</p><p>deve atingir, mesmo em momentos de problemas.</p><p>— Facilidade na recuperação: está ligada à capacidade do software de se restabelecer, e de</p><p>restabelecer seus dados e parâmetros sem que haja necessidade de intervenção, após uma</p><p>falha.</p><p>•	 Usabilidade</p><p>— Inteligibilidade: medida da facilidade do usuário para reconhecer a lógica de funcionamento</p><p>do software.</p><p>— Facilidade no aprendizado: medida da facilidade encontrada pelo usuário para aprender a</p><p>utilizar o software.</p><p>— Operacionalidade: medida da facilidade para operar o produto com segurança e sem falhas.</p><p>•	 Eficiência</p><p>— Comportamento em relação ao tempo: está relacionado ao tempo de resposta e de</p><p>processamento do software em seus serviços.</p><p>25</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>— Utilização de recursos: está relacionada à quantidade de recursos utilizados (CPU, memória,</p><p>processador) e ao tempo de resposta e de processamento do software em seus serviços.</p><p>•	 Manutenibilidade</p><p>— Facilidade na análise: medida do esforço necessário para diagnosticar falhas e localizar as</p><p>partes para corrigir os problemas.</p><p>— Facilidade na alteração: medida do esforço necessário para corrigir as falhas ou adequar o</p><p>produto a eventuais mudanças.</p><p>— Facilidade na estabilização: medida do esforço necessário em se estabilizar o software após as</p><p>alterações.</p><p>— Facilidade no teste: medida do esforço necessário para testar o produto de software alterado.</p><p>•	 Portabilidade</p><p>— Adaptabilidade: está ligada à facilidade em se adaptar o software para funcionar em outros</p><p>ambientes.</p><p>— Capacidade para ser instalado: medida do esforço necessário para instalar o software em um</p><p>ambiente de operação.</p><p>— Coexistência: está relacionado ao nível de conformidade do software a padrões referentes à</p><p>portabilidade.</p><p>— Capacidade para substituir: medida do esforço necessário em substituir um software por outro</p><p>previamente especificado.</p><p>Os atributos de qualidade listados na ISO 25010 (2011a) também são tratados na engenharia de</p><p>requisitos como requisitos não funcionais. É apenas uma questão de mudança de enfoque: enquanto</p><p>esses atributos de qualidade, na engenharia de requisitos, são tratados como requisitos não funcionais,</p><p>no projeto, são tratados como diretivas de qualidade de projeto.</p><p>Saiba mais</p><p>A qualidade de software é disciplina extensa e muito importante para ser</p><p>debatida apenas no contexto deste livro-texto. Veja no trabalho de Guerra</p><p>e Colombo (2009) como a norma ISO 9126 (que é a norma predecessora da</p><p>ISO 25010) pode ser aplicada na avaliação da qualidade:</p><p>GUERRA, A. C.; COLOMBO, R. M. T. Tecnologia da informação: qualidade</p><p>de produto de software. Brasília: PBQP, 2009.</p><p>26</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>2.7 Introdução ao projeto orientado a objetos</p><p>O projeto orientado a objetos partilha exatamente dos mesmos princípios e objetivos que debatemos</p><p>até agora, ou seja, possui as mesmas fases, é baseado na produção de modelos, é fundamentado nos</p><p>mesmos conceitos básicos, aspectos humanos e objetivos.</p><p>Mas então qual é a diferença?</p><p>A diferença fundamental está na utilização do paradigma da orientação a objetos e de seus conceitos</p><p>fundamentais.</p><p>Um paradigma é um conjunto de regras que ajuda-nos a organizar e</p><p>a coordenar a maneira como olhamos o mundo entre o que é certo</p><p>e errado, entre o que é verdadeiro e o que é falso, entre o que se deve</p><p>fazer e o que não se deve fazer. [...] Ele funciona como um conjunto</p><p>de categorias que define e orienta o comportamento das pessoas</p><p>(CHIAVENATO, 2008, p. 8).</p><p>O paradigma da orientação a objetos é uma forma de se desenvolver um sistema de software que o</p><p>enxerga como um conjunto de componentes que interagem para resolver um determinado problema. A</p><p>cada componente, dá-se o nome de objeto.</p><p>A motivação da abordagem orientada a objetos se dá pela tentativa de aproximar o desenvolvimento</p><p>de software daquilo que acontece no mundo real.</p><p>Vamos relembrar um pouco os conceitos fundamentais do paradigma da orientação a objetos.</p><p>Podemos dizer que esses conceitos são básicos para conseguirmos desenvolver a fase de projeto.</p><p>O paradigma da orientação a objetos é baseado nos seguintes pilares.</p><p>Classes</p><p>Podemos definir classe, ou classe de objetos, como um grupo de objetos com iguais propriedades</p><p>(atributos), comportamento (operações), relacionamentos e semântica.</p><p>Uma classe deve possuir responsabilidades bem-definidas, e cada responsabilidade representa</p><p>um contrato ou obrigações dela.</p><p>Semanticamente, dizemos que uma classe é uma especificação de um objeto, pois nela está definido</p><p>tudo o que o objeto possui (atributos) e tudo aquilo que o objeto pode fazer (métodos).</p><p>27</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Objeto</p><p>Podemos afirmar que todo objeto possui uma identidade, representada por um conjunto de</p><p>informações conferidas aos seus atributos, e ainda que todo objeto possui um estado, definido também</p><p>pelo conjunto dessas informações em um determinado espaço de tempo.</p><p>Encapsulamento</p><p>Encapsulamento significa deixar visível, ou deixar acessível a outros objetos, apenas o que é necessário.</p><p>Por exemplo, podemos ocultar dos demais objetos de um sistema detalhes da implementação ou</p><p>a lógica algorítmica de um método de um determinado objeto, uma vez que esses detalhes não são</p><p>importantes para os demais, apenas para o objeto que possui essa lógica.</p><p>Para os demais objetos que se comunicam com esse objeto, basta que ele faça o que deve fazer, não</p><p>sendo importante o como será feito.</p><p>Abstração</p><p>Abstração é um dos principais conceitos aplicados à resolução de problemas, que é fundamental</p><p>para a modelagem da estrutura de um sistema de software.</p><p>Está ligada a nossa capacidade de selecionar determinados aspectos do problema e isolar o que</p><p>é importante para algum propósito do que não for para um determinado propósito, ou seja, é dar</p><p>ênfase àquilo que é necessário. Um conceito que parece simples à primeira vista, entretanto faz toda a</p><p>diferença na resolução e na modelagem de sistemas complexos.</p><p>Na modelagem de um sistema de software, abstração está relacionada à nossa capacidade, enquanto</p><p>analistas, desenvolvedores e arquitetos, de estabelecer um modelo de objetos que resolva o problema da</p><p>melhor forma possível, isto é, não basta resolver o problema, é preciso pensar em cada objeto como uma</p><p>unidade autônoma, ou seja, fazendo única e exclusivamente aquilo que precisa fazer e tendo apenas as</p><p>dependências que deve ter.</p><p>A melhor forma de se representar a estrutura estática de um sistema orientado a objetos é utilizando</p><p>o modelo de classes. São três os modelos utilizados, segundo Bezerra (2006).</p><p>•	 Modelo	de	classe	de	domínio:	desenvolvido	na	fase	de	análise,	o	modelo	de	classe	de	domínio</p><p>representa os objetos, ou classes, inerentes ao domínio do problema que queremos resolver,</p><p>deixando de lado, nesta visão, detalhes tecnológicos da solução do problema.</p><p>•	 Modelo	 de	 classe	 de	 especificação:	 construído	 na	 fase	 de	 projeto,	 o	 modelo	 de	 classe	 de</p><p>especificação adiciona ao modelo de classes de domínio, objetos ou classes específicas para a</p><p>solução do problema sob o aspecto tecnológico, ou seja, é uma extensão do modelo de classe de</p><p>domínio.</p><p>28</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>•	 Modelo	de	classe	de	implementação:	o	modelo	de	implementação	nada	mais	é	que	a	implementação</p><p>das classes, especificadas no modelo de especificação, construídas ou codificadas em alguma</p><p>linguagem de desenvolvimento orientada a objetos, como a linguagem Java ou a linguagem C#.</p><p>Observação</p><p>Atualmente existe uma distorção grande quando falamos de</p><p>orientação a objetos e linguagem de desenvolvimento, ou programação</p><p>orientada a objetos. Como vimos, orientação a objetos é um paradigma,</p><p>não uma linguagem. Todavia, as linguagens possibilitam ao desenvolvedor</p><p>implementar um software baseado nesse paradigma.</p><p>Dentro do ciclo de vida da engenharia de software, nas atividades ou fases anteriores à fase de</p><p>projeto, a ênfase é dada ao modelo de classe de domínio e à elicitação de requisitos nos quais eram</p><p>produzidos artefatos utilizando como suporte, principalmente, a Unified Modeling Language (UML)</p><p>como uma ferramenta para representação e modelagem de um sistema de software.</p><p>Saiba mais</p><p>A especificação e a definição completas da UML estão disponíveis no</p><p>site da OMG:</p><p>.</p><p>Pois bem, no paradigma da orientação a objetos, a fase de projeto utiliza como espinha dorsal</p><p>todos os princípios da fase de projetos que vimos até agora, soma-se aos conceitos fundamentais da</p><p>orientação a objetos e adentra o modelo de classes de especificação apresentados por Bezerra (2006).</p><p>O objetivo da fase de projetos no paradigma da orientação a objetos é dar sequência ao modelo</p><p>de classes de domínio, transformando as classes que possuem alto nível de abstração, utilizadas</p><p>fundamentalmente para o entendimento do problema, em classes de projeto.</p><p>Classes de projeto é um nível mais baixo de abstração, ou, podemos dizer, um nível mais refinado das</p><p>classes de análise, que possuem maiores detalhes de implementação, de infraestrutura que suportarão</p><p>a concretização das regras de negócio (PRESSMAN, 2006).</p><p>Assim como os componentes de software, que citamos anteriormente, as classes (que também podem</p><p>ser enxergadas como componentes em outro nível de abstração) devem ser e possuir, respectivamente:</p><p>completa e suficiente, ou seja, devem possuir nível suficiente de encapsulamento e de número de</p><p>funcionalidade. Não deve fazer mais, nem menos; alta coesão e baixo acoplamento.</p><p>29</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Ambler (2001 apud Pressman, 2006, p. 219) enumera os cinco tipos de classes de projetos que</p><p>podem ser desenvolvidas na fase de projetos:</p><p>•	Classes	de	interface	do	usuário:	definem	a	interação	homem-máquina</p><p>ou IHC (interação homem-computador).</p><p>•	Classes	de	domínio	de	negócio:	são	refinamentos	das	classes	do	modelo</p><p>de domínio (ou de análise). Possuem atributos e métodos utilizados</p><p>para implementar elementos do domínio do negócio.</p><p>•	Classes	de	processos:	têm	como	objetivo	gerir	as	classes	de	domínio</p><p>de negócio.</p><p>•	Classes	persistentes:	têm	como	objetivo	a	persistência	de	informações</p><p>em um repositório de dados, por exemplo, um banco de dados.</p><p>•	Classes	de	sistema:	têm	como	objetivo	gerir	a	comunicação	do	software</p><p>com o seu ambiente computacional interno e externo.</p><p>Coad e Yourdon (1993) têm uma visão semelhante, mas polarizada um pouco mais para a visão</p><p>arquitetural; enxergando os componentes de um software como uma composição de classes, definem</p><p>quatro tipos de componentes:</p><p>•	 Componente	 do	 domínio	 do	 problema:	 são	 componentes	 responsáveis	 por	 implementar	 os</p><p>requisitos dos usuários.</p><p>•	 Componente	de	interação	humana:	são	componentes	responsáveis	por	implementar	a	interação</p><p>homem-máquina ou IHC (interação homem-computador).</p><p>•	 Componente	de	gerência	de	tarefa:	são	responsáveis	por	controlar	e	coordenar	tarefas	do	software.</p><p>•	 Componente	de	gerência	de	dados:	são	responsáveis	por	controlar	a	persistência	dos	objetos	em</p><p>um repositório de dados.</p><p>Nas próximas unidades iremos trabalhar como modelar e representar a evolução do modelo de domínio</p><p>para o modelo de projetos, como iremos representar os tipos de classe de projeto e componentes de</p><p>projeto, associando aos artefatos que devem ser produzidos, tendo como suporte os diagramas da UML.</p><p>resumo</p><p>Esta unidade teve como objetivo apresentar os conceitos introdutórios e</p><p>fundamentais sobre projeto de sistemas no paradigma da orientação a objetos.</p><p>Iniciou-se com o debate e o convite a debatermos sobre a real motivação</p><p>em seguir um modelo de projetização.</p><p>30</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>Traçando um paralelo, vimos que, muito em função do seu tempo de</p><p>existência, incomparavelmente maior, a engenharia civil está muito mais</p><p>avançada no aspecto projeto que a engenharia de software.</p><p>Construir um software sem um projeto é como construir uma casa</p><p>sem um projeto, que engloba, dentre outras coisas, um conjunto de</p><p>plantas e modelos que representam a casa e servem de guia para essa</p><p>construção.</p><p>Na engenharia de software temos diversas opções de modelos de</p><p>processo, ou de ciclo de vida, para desenvolvimento de projetos de software,</p><p>por exemplo, o Modelo Cascata (waterfall), o Modelo Iterativo Incremental,</p><p>Modelo Espiral e o Processo Unificado (UP).</p><p>Esses modelos definem e direcionam uma sequência de fases e de</p><p>atividades realizadas dentro de cada fase com o objetivo de organizar o</p><p>desenvolvimento de um produto de software.</p><p>Qualquer que seja o modelo de processo adotado, a fase de projetos</p><p>está sempre entre a fase de elicitação e análise de requisitos e a construção</p><p>ou desenvolvimento.</p><p>O objetivo da fase de projetos é desenhar a solução para os problemas</p><p>levantados na engenharia de requisitos, desenho esse que serve como guia</p><p>para a construção.</p><p>A fase de projetos não é iniciada até que todos os requisitos, ou parte</p><p>deles, sejam elicitados, documentados e aprovados. Depende do modelo de</p><p>ciclo de vida adotado, em que poderão ser mapeados e validados todos os</p><p>requisitos do sistema, como no Modelo Tradicional ou apenas uma parte</p><p>desses requisitos, como no Modelo Iterativo Incremental.</p><p>No Modelo Cascata, por exemplo, todos os requisitos são levantados,</p><p>e após isso se inicia a fase de projetos, enquanto em um Modelo Iterativo</p><p>Incremental, a cada iteração, uma fatia do total dos requisitos é elicitada e</p><p>validada para depois se iniciarem as atividades da fase de projetos.</p><p>Vimos que, assim como na engenharia civil, que possui plantas de casas</p><p>como modelos, a técnica de modelagem é fundamental na fase de projeto</p><p>de um software.</p><p>Um modelo é uma abstração, uma representação de uma perspectiva</p><p>do sistema, utilizada para dar ênfase a aspectos importantes, deixando</p><p>aspectos menos importantes de lado para facilitar o entendimento.</p><p>31</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Modelos são fundamentais, pois ajudam no gerenciamento da</p><p>complexidade, na comunicação entre os envolvidos no projeto, reduzem</p><p>os custos do desenvolvimento e simulam o comportamento do sistema,</p><p>servindo, assim, como um laboratório.</p><p>Dois são os conceitos fundamentais quando estamos modelando um</p><p>sistema na fase de projetos: abstração e modularidade.</p><p>Abstração, que também é um dos conceitos fundamentais da orientação</p><p>a objetos, está ligada a nossa capacidade, enquanto analistas e projetistas, de</p><p>enxergar aspectos relevantes à solução de um problema no seu devido tempo.</p><p>Modularidade é a divisão do software em componentes, ou módulos,</p><p>que interagem para resolver um determinado problema. Todavia, a simples</p><p>modularização não resolve os desafios de se produzir um software com</p><p>qualidade.</p><p>O que se busca com a modularidade é: baixo acoplamento e alta</p><p>coesão. Isso se dá a partir do uso de técnicas de encapsulamento e de uma</p><p>divisão de responsabilidade de cada módulo, de tal forma que eles tenham</p><p>funções bem-definidas. Cada componente não deve “fazer demais”, nem</p><p>“fazer pouco”.</p><p>Dentro da fase de projeto, temos uma subdivisão em quatro</p><p>atividades (ou fases): projeto de componentes, projeto de interfaces,</p><p>projeto arquitetural e projeto de dados/classes; cada fase é delimitada</p><p>pelos artefatos que produz.</p><p>Vimos que alguns dos principais envolvidos na fase de projetos</p><p>são: o arquiteto, o analista, o gerente de projetos, os stakeholders e os</p><p>desenvolvedores, estes últimos em menor grau nessa fase.</p><p>São três os objetivos a serem atingidos pelos profissionais envolvidos</p><p>na fase de projetos: o modelo do software deve ser um guia não só para a</p><p>implementação, que é o principal, mas para todas as fases subsequentes; deve</p><p>fornecer uma visão completa da solução; e deve contemplar todos os requisitos</p><p>explícitos mapeados na engenharia de requisitos e, principalmente, estar pronto,</p><p>ou apto, aos possíveis, e prováveis, requisitos implícitos.</p><p>Além desses três objetivos, vimos que a norma ISO 25010 (2011a)</p><p>utilizada na engenharia de requisitos para determinar um conjunto de</p><p>requisitos não funcionais, é utilizada na fase de projetos como uma baliza</p><p>para a avaliação da qualidade de um produto de software, em um mercado</p><p>cada vez mais competitivo.</p><p>32</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Unidade I</p><p>O projeto orientado a objetos utiliza-se da espinha dorsal de todos os</p><p>princípios e objetivos de projeto e, somando-se aos pilares do paradigma</p><p>da orientação a objetos, refina o modelo de classes de domínio, obtido na</p><p>fase de análise com o objetivo de montar um modelo de classes que possa</p><p>efetivamente ser construído.</p><p>O objetivo das próximas unidades é construir o modelo de classes de</p><p>projeto, com todos os tipos de classes: de domínio de negócio, de interface</p><p>do usuário, de processos, persistentes e de sistema e seus respectivos</p><p>artefatos, tendo como base o paradigma da orientação a objetos e seus</p><p>conceitos fundamentais e a UML como ferramenta de apoio.</p><p>exercícios</p><p>Questão 1. O modelo cascata, também conhecido como ciclo de vida clássico, requer uma</p><p>abordagem sistemática e sequencial. Esta abordagem apresenta algumas deficiências que são, em parte,</p><p>endereçadas a outros modelos, como o espiral e os atuais métodos ágeis.</p><p>Considerando as características do modelo cascata, avalie as afirmativas a seguir:</p><p>I – Em projetos complexos demora-se muito para se obter o software em execução.</p><p>II – Erros ocorridos nas etapas de levantamento e análise só são percebidos em fases avançadas, o</p><p>que maximiza o custo de correção destes.</p><p>III – Dificilmente consegue-se listar todos os requisitos do software logo no início do projeto.</p><p>IV – Este modelo pressupõe interação e entrega de pequenos módulos e pacotes de software aos</p><p>usuários, na medida em que o projeto avança.</p><p>V – Uma versão executável do software só é disponível em uma fase avançada do modelo.</p><p>É correto apenas o que se afirma em:</p><p>A) I e II.</p><p>B) II e IV.</p><p>C) I, II, III e V.</p><p>D) I, II e III.</p><p>E) II, III e V.</p><p>Resposta correta: alternativa C.</p><p>33</p><p>AD</p><p>S</p><p>-</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>M</p><p>ar</p><p>ci</p><p>lia</p><p>-</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: F</p><p>ab</p><p>io</p><p>-</p><p>0</p><p>8/</p><p>05</p><p>/2</p><p>01</p><p>5</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Análise das afirmativas</p><p>I – Afirmativa correta.</p><p>Justificativa: o modelo cascata pressupõe que uma fase ou etapa termine para que a outra comece,</p><p>desta forma o software só é disponibilizado para uso ao final do projeto de desenvolvimento.</p><p>II – Afirmativa correta.</p><p>Justificativa: os testes, atividades que permitem que o usuário tenha contato com o sistema,</p><p>são realizados ao final da fase de codificação e na fase de testes. Estas vêm após as fases iniciais de</p><p>levantamento e análise. Sendo assim, o acerto de erros nas primeiras fases pressupõe ajustes em quase</p><p>todo o ciclo de vida transcorrido até o momento.</p><p>III – Afirmativa correta.</p><p>Justificativa: por mais amplo que seja o levantamento de requistos é comum que novos requsitos</p><p>apareçam durante o projeto. Quanto mais longo for o projeto maior é a probabilidade do aparecimento</p><p>de novos requisitos.</p><p>IV – Afirmativa incorreta.</p><p>Justificativa: este modelo não pressupõe interação e entrega de pequenos módulos e pacotes de</p><p>software aos usuários na medida em que o projeto avança.</p><p>V – Afirmativa correta.</p><p>Justificativa: pela característica de ser sequencial, somente em uma fase avançada é que se</p><p>disponibiliza uma versão executável do software.</p><p>Questão 2. O paradigma da orientação a objetos é uma forma de se desenvolver um sistema de</p><p>software que o enxerga como um conjunto de componentes que interagem entre si para resolver um</p><p>determinado problema.</p><p>De acordo com este paradigma, cada componente é chamado de:</p><p>A) Classe.</p><p>B) Classe persistente.</p><p>C) Método.</p><p>D) Objeto.</p><p>E) Herança.</p><p>Resolução desta questão na plataforma.</p><p>34</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Unidade II</p><p>3 TECNOLOGIA DE APOIO AO PROJETO ORIENTADO A OBJETOS</p><p>3.1 A UML</p><p>Antes de nos aprofundarmos sobre o tema, listaremos a seguir, algumas das principais confusões a</p><p>respeito da UML.</p><p>A UML não é:</p><p>•	 Uma	linguagem	de	programação.</p><p>•	 Uma	plataforma	de	desenvolvimento.</p><p>•	 Uma	ferramenta	de	modelagem.</p><p>•	 Um	software.</p><p>A	UML	(Unified	Modeling	Language),	na	definição	de	seus	criadores,	Booch,	Jacobson	e	Rumbaugh</p><p>(2006,	 p.13)	 “é	 uma	 linguagem-padrão	 para	 elaboração	 da	 estrutura	 de	 projetos	 de	 software [...]</p><p>adequada para a modelagem de sistemas”.</p><p>Os autores ainda pontuam:</p><p>•	 A	UML	é	apenas	uma	linguagem.</p><p>•	 É	independente	do	modelo	de	processo	adotado.</p><p>•	 É	destinada	a	visualização,	especificação	e	documentação	de	artefatos.</p><p>Vamos	então	tentar	desmitificar	um	a	um	os	mal-entendidos	acerca	da	UML.</p><p>•	 Uma	linguagem	de	programação</p><p>A	UML	não	é	uma	 linguagem	de	programação,	muito	embora	 seja	possível	a	geração	de	código</p><p>a	partir	de	alguns	diagramas,	o	diagrama	de	classes	principalmente,	assim	como	o	inverso,	ou	seja,	a</p><p>geração	de	diagramas	a	partir	de	código-fonte.</p><p>35</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Projeto de SiStemaS orientado a objetoS</p><p>Todavia	é	importante	que	se	tenha	em	mente	que	a	geração	de	código	não	é	algo	propriamente	da</p><p>UML,	mas	sim	de	ferramentas	de	modelagem	que	tenham	a	UML	como	padrão	e	que	tenham	recursos</p><p>para	geração	de	código	ou	de	engenharia	reversa.</p><p>•	 Uma	plataforma	de	desenvolvimento.</p><p>•	 Uma	ferramenta	de	modelagem.</p><p>•	 Um	software.</p><p>Existem	inúmeras	ferramentas	no	mercado	que	se	utilizam	da	UML	para	a	geração	de	diagramas,	mas</p><p>a	UML	em	si	não	pode	ser	considerada	uma	plataforma	ou	uma	ferramenta	de	modelagem,	tampouco</p><p>um software.</p><p>A	confusão,	nesse	ponto,	dá-se	pela	falsa	sensação	de	que	não	conseguimos	trabalhar	com	UML	e</p><p>desenvolver	diagramas	sem	que	tenhamos	uma	ferramenta	de	modelagem.</p><p>Nesse	caso,	as	ferramentas	de	modelagem	são	importantes	facilitadores	na	utilização	da	UML	e</p><p>nada mais.</p><p>Assim	como	na	fase	de	análise,	ou	na	disciplina	de	análise	de	sistemas	OO,	na	fase	de	projetos	a	UML</p><p>é	uma	das	principais	ferramentas	de	apoio	para	a	modelagem	da	solução.</p><p>Mas	antes	de	saber	como	utilizar	um	diagrama,	precisamos	saber	quais	diagramas	devemos	utilizar</p><p>e	em	quais	circunstâncias,	dentro	da	atividade	de	projetos.</p><p>Segundo	a	abordagem	de	Kruchten	(1995),	um	sistema	de	software	pode	ser	organizado	em	cinco</p><p>visões,	e	cada	visão	possui	um	conjunto	de	diagramas	UML,	que	representam	aspectos	particulares</p><p>desse sistema.</p><p>Saiba mais</p><p>A	mesma	divisão	pode	ser	vista,	em	menor	grau	de	detalhe,	em:</p><p>BOOCH,	G.;	JACOBSON,	I.;	RUMBAUGH,	J.	UML:	guia	do	usuário.	2.	ed.</p><p>Rio	de	Janeiro:	Campus,	2006.</p><p>A	figura	a	seguir	demonstra	as	cinco	visões	propostas	por	Kruchten	(1995)	e	por	Booch,	Jacobson	e</p><p>Rumbaugh	(2006):</p><p>36</p><p>Re</p><p>vi</p><p>sã</p><p>o:</p><p>N</p><p>om</p><p>e</p><p>do</p><p>re</p><p>vi</p><p>so</p><p>r -</p><p>D</p><p>ia</p><p>gr</p><p>am</p><p>aç</p><p>ão</p><p>: N</p><p>om</p><p>e</p><p>do</p><p>d</p><p>ia</p><p>gr</p><p>am</p><p>ad</p><p>or</p><p>-</p><p>d</p><p>at</p><p>a</p><p>Unidade II</p><p>Visão	de</p>