Projeto de Sistemas - 2011/2

Roteiro do Trabalho Prtico

O trabalho prtico consta da realizao das atividades de Projeto da Arquitetura de

Software e Projeto dos Componentes da Arquitetura, devendo ser apresentados os produtos
de trabalho gerados por essas atividades, segundo o modelo de documento Modelo de
Documento de Projeto. Os produtos devem estar compatveis, tambm, com os padres de
nomenclatura estabelecidos neste documento. Como exemplo, ver a soluo do exerccio
exemplo.
Devem ser observados atentamente os seguintes aspectos:
Todos os artefatos de texto devero ser produzidos utilizando o editor de texto
do BrOffice, verso 3.3.0 ou superior, disponvel em http://www.broffice.org/.
Para a construo de modelos UML, deve ser utilizada a ferramenta Astah
Community, verso 6.3 ou superior, disponvel em http://astah.changevision.com/en/product/astah-community.html.
A entrega dos trabalhos deve ser feita por email para falbo@inf.ufes.br, at o
prazo estabelecido no cronograma da disciplina, disponvel em
http://www.inf.ufes.br/~falbo/node/10.

Parte 1
A 1 parte do trabalho prtico consta da definio da plataforma de implementao
do sistema e do estabelecimento das tticas a serem aplicadas para tratar os atributos de
qualidade identificados no Documento de Requisitos.
Inicialmente dever ser definida a plataforma de implementao do sistema e
preenchida a seo 2 (Plataforma de Implementao) do Documento de Projeto de
Sistema (ver padro Modelo de Documento de Projeto). Na sequncia, os requisitos no
funcionais devero ser analisados e, em funo de suas prioridades, estabelecidos aqueles
que sero definidos como sendo atributos de qualidade condutores do projeto da arquitetura
e as tticas utilizadas para trat-los. Como resultado, deve ser preenchida a seo 3
(Atributos de Qualidade e Tticas) do Documento de Projeto de Sistema.

Parte 2
A 2 parte do trabalho prtico consta da realizao do projeto da arquitetura de
software e do projeto do componente de domnio do problema (CDP).
Inicialmente, deve ser projetada a arquitetura do sistema, gerando o diagrama de
pacotes correspondente e preenchendo a seo 4 (Arquitetura de Software) do documento.
Uma vez definida a arquitetura de software, devem ser projetados os Componentes
de Domnio de Problema (CDP) relativos a cada um dos subsistemas identificados na

arquitetura. O projeto do CDP deve ser feito a partir dos correspondentes diagramas de
classes da fase de modelagem conceitual estrutural. Assim, antes mesmo de iniciar o
projeto da arquitetura, copie o arquivo Astah que contm o Modelo de Anlise, dando
origem a um novo arquivo, o Modelo de Projeto. Faa o projeto da arquitetura nesse novo
arquivo e, uma vez definidos os pacotes do CDP, movimente diagramas e correspondentes
classes para esses pacotes. A partir desses diagramas, faa as alteraes pertinentes
relativas fase de projeto. Por fim, preencha as subsees correspondentes subseo
5.1.1.1 (Componente de Domnio do Problema) do Documento de Projeto de Sistema.

Parte 3
A 3 parte do trabalho prtico consta da realizao do projeto dos Componentes de
Gerncia de Tarefas (CGT), Interface com o Usurio (CIU) e Gerncia de Dados (CGD).
Os diagramas de classes correspondentes devem ser produzidos, bem como devem ser
preenchidas as demais subsees da seo 5 do Documento de Projeto de Sistema. Esta
parte do trabalho deve ser feita para apenas um dos subsistemas definidos na arquitetura do
software, a ser indicado pelo professor.
Uma vez que o projeto do CGT est fortemente relacionado ao projeto do CIU, o
projeto desses dois componentes deve ser elaborado em paralelo. Para este trabalho prtico,
deve ser selecionado um fluxo de eventos de caso de uso contendo a lgica principal do
negcio apoiado pelo sistema, para o qual dever ser elaborado um diagrama de sequncia.
Esse diagrama de sequncia visa capturar a interao entre as classes dos componentes
CIU, CGT e CDP.
Para o projeto das classes de viso, devem ser elaborados prottipos das interfaces
grficas, mostrando os layouts das classes de viso envolvidas no diagrama de sequncia
elaborado. Vale ressaltar que o projeto das interfaces grficas (layouts) deve ser elaborado
apenas para as interfaces grficas envolvidas no diagrama de sequncia elaborado. Essas
interfaces grficas devem ser produzidas utilizando os recursos da plataforma de
implementao definida. Opcionalmente, poder-se- utilizar um software para a
prototipagem de interfaces.
Por fim, deve ser realizado o projeto da persistncia, elaborando os diagramas de
classes dos pacotes CGD definidos na arquitetura. Utilitrios utilizados devem ser
apresentados no Documento de Projeto de Sistema.

Usando o Modelo de Documento

O Documento de Projeto de Sistema deve ser construdo tomando por base o
Modelo de Documento de Projeto. Para tal, abra o modelo de documento e o renomeie de
acordo com o padro de nomes definido abaixo. Preencha os campos do modelo de
documento, preservando a formatao. Utilize somente o editor de textos do BrOffice.
Em nenhuma hiptese utilize outro editor que seja capaz de ler e editar o formato odt.
Para a elaborao dos diagramas UML correspondentes, deve ser usada a ferramenta
Astah. O arquivo Astah correspondente deve ser enviado junto com o Documento de
Projeto de Sistema, a partir da 2 parte do trabalho. Esse arquivo deve ser nomeado
conforme o padro de nomes para arquivos, descrito a seguir.

Padro de nomes para arquivos de documentos

Documento de Projeto de Sistema:
Documento_Projeto_v<no da verso no formato x.y>.odt
Ex.: Documento_Projeto_v1.0.odt
Modelos UML de Projeto:
Modelo_Projeto_v<nmero da verso no formato x.y>.odt
Ex.: Modelo_Projeto_v1.0.odt

Padro de Nomes
No que se refere nomeao dos diversos elementos de modelo dos diagramas
UML a serem produzidos, os seguintes padres devem ser respeitados:
Diagramas de Pacotes

Pacotes: o nome de um pacote deve ser um substantivo no singular,

possivelmente combinado com algum complemento. Preposies devem ser
omitidas e o nome do pacote deve ser iniciado com letra minscula. Nomes dos
complementos devem ser iniciados com letra maiscula, sem espao em relao
palavra anterior. Ex.: controleAcervo, atendimentoCliente.

Diagramas de Classes

Classes: o nome de uma classe deve iniciar com um substantivo no singular, o

qual pode ser combinado com complementos ou adjetivos. Preposies devem
ser omitidas e o nome da classe deve ser iniciado com letra maiscula. Nomes
dos complementos devem ser iniciados tambm com letra maiscula, sem dar
um espao em relao palavra anterior. Acentos no devem ser utilizados. Ex.:
Cliente, PessoaFisica, ItemPedido.

Classes do CDP: Valem as regras gerais para classes.

Classes do CGT: Alm das regras gerais, aplica-se a seguinte regra: Todas as
classes do CGT devem iniciar com o prefixo Apl, seguido de verbo no
infinitivo, indicando o caso de uso contemplado pela classe. Quando a classe de
GT tratar de um nico caso de uso, o nome desse caso de uso deve ser usado
como complemento do nome da classe. Ex.: AplCadastrarCliente, tratando
somente da lgica de aplicao envolvida no caso de uso Cadastrar Cliente.
Quando a classe de GT tratar de mais de um caso de uso, o nome dessa classe
deve ser composto de modo a fazer uma referncia aos casos de uso envolvidos.
Ex.1: AplEfetuarLocacaoDevolucao, tratando da lgica de aplicao envolvida
nos casos de uso Efetuar Locacao e Efetuar Devolucao.
Ex.2: AplControlarAcervo, tratando da lgica de aplicao envolvida em todos
os casos de uso do subsistema controleAcervo.

Classes do CIU: Alm das regras gerais, aplicam-se as seguintes regras:

o Classes controladoras de interao devem ser iniciadas pelo prefixo Ctrl,
seguido de complemento que indique a extenso do controle exercido
pela classe. Ex.: CtrlControleAcervo, classe controladora de toda a
interao do subsistema controleAcervo.
o Classes de viso devem ser iniciadas por um prefixo que indique o tipo
de interface (Jan para janela, Painel para painel etc), seguido de
complemento que indique o contexto em que a interface grfica est
sendo aplicada. Ex.: JanCadastrarCliente, PainelDadosCliente,
JanPrincipal.

Classes do CGD: Alm das regras gerais, aplica-se a seguinte regra: Todas as
classes do CGD devem iniciar com o nome da classe do CDP pela qual a classe
do CGD responsvel pelo armazenamento e recuperao de dados. Um sufixo
padro deve ser utilizado em funo do padro de persistncia adotado. Ex.:
ClienteDAO, quando o padro DAO adotado; ClientePersistente etc.

Atributos: o nome de um atributo deve iniciar com um substantivo, sempre

comeando com letra minscula. Havendo mais de uma palavra, estas comeam
com letra maiscula. Acentos e preposies no devem ser utilizados. Atributos
monovalorados devem iniciar com substantivo no singular. Ex.: nome,
razaoSocial. Atributos multivalorados devem iniciar com substantivo no plural.
Ex.: telefones.

Associaes: devem ser nomeadas usando um verbo conjugado, indicando o

sentido de leitura. Ex.: Cliente (classe) efetua > (associao) Locao (classe).

Papis de Associaes: as mesmas regras usadas para atributos aplicam-se a

papis de associao.

Operaes: o nome de uma operao deve iniciar com um verbo no infinitivo,

sempre comeando com letra minscula. Havendo mais de uma palavra, estas
comeam com letra maiscula. Acentos e preposies no devem ser utilizados.
Ex.: calcularDataDevolucaoPrevista. As seguintes excees devem ser
observadas:

o Operaes bsicas de recuperao de valor de um atributo ou associao:

deve ser usado o verbo em ingls get, seguido do nome do correspondente
atributo / papel da associao. Ex.: getNome, getTelefones.
o Operaes bsicas de atribuio de valor de um atributo ou associao: deve
ser usado o verbo em ingls set, seguido do nome do correspondente atributo
/ papel da associao. Ex.: setNome, setRazaoSocial.
o Operaes de verificao de estado ou tipo de um objeto, cujo retorno
verdadeiro ou falso: deve ser usado o verbo ser ou o verbo estar, conjugado
como uma pergunta. A letra h deve ser usada para indicar o acento.
Preposies podem ser usadas quando forem importantes para indicar o
estado que est sendo avaliado. Ex.: estahAtivo, estahEmDebito.

Operaes das classes do CGT: Alm das regras gerais para operaes, aplica-se
a seguinte regra: Os nomes das operaes devem corresponder fielmente aos
nomes dos fluxos de eventos envolvidos nos casos de uso tratados pelas classes
de GT.

Parmetros de operaes: as mesmas regras usadas para atributos aplicam-se

para parmetros de operaes.