Portfólio POO- diargama UML LojaAssitenciaTecnica

Prévia do material em texto

3 
3 
3 
 
 
CLARETIANO CENTRO UNIVERSITÁRIO 
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
 PROGRAMAÇÃO ORIENTADA A OBJETOS 
 
 
 
 
 
 
ÍTALO FERREIRA CELANI 
 
 
 
 
 
 
PORTFÓLIO-01 
 Ciclo-01 
 Lisboa-PT 
 2023 
ÍTALO FERREIRA CELANI 
 
 
 
 
 
 
PORTFÓLIO-01
Ciclo-01 
 
 
 
 
 
 
Portfólio apresentado ao curso de Análises e Desenvolvimento de Sistemas, do Claretiano Centro Universitário, como requisito parcial para obtenção do grau, sendo este um trabalho acadêmico, em meu curso. 
 
 
 
 
 
 
Professor / Tutor a Distância/ Professor Responsável: Jeane Aparecida Menegueli
 
 
 
Lisboa-PT 
2023 
 
 
SUMÁRIO 
 
1 INTODUÇÃO ………………………………………………………………….….. 3 
2 CONTEÚDO……………………………………………………………...….……. 4 
2.1 Atividade/Exercício de abstração e representação.................................4 
3 CONCLUSÃO ………………………………………………………………...…..13
 
 REFERÊNCIAS…………………………………………………………….…….…14
LISTA DE FIGURAS
Figura 01………………………………………………………….…................….....…05
Figura 02…………………………………………………………….…...............…..…06
Figura 03…………………………………………………………….…...............…..…06
Figura 04………………………………………………………...............…….……..…07
Figura 05…………………………………………………………….…….................…07
Figura 06…………………………………………………………...............….……..…08
Figura 07…………………………………………………………….…...............…..…08
Figura 08…………………………………………………………….…….................…09
Figura 09………………………………………………………….……....................…12
 
 
 
 
 
 
 
1 INTRODUÇÃO 
 
A apresentação desta atividade será realizada por meio representacção de um diagrama de classes. Para criar o digrama foi usado a ferramenta ASTAH UML, uma ferramenta para modelagem que permite a visualização da essência de idéias e projetos de software. O ASTAH oferece diargamas UML, diagramas ER, diagramas de fluxo de dados, fluxogramas, mapas mentais e etc.
No domínio de uma aplicação para uma Loja de Assistência técnica observa-se a ocorrência das seguintes entidades: Técnico, Atendente, Cliente, Serviço, Solicitação de Serviço e Material.
Primeira Parte:
Ao elaborar o diagrama observe se existem características semelhantes. Portanto, considere o conceito de Generalização. 
Segunda Parte:
Verifique os relacionamentos entre as classes. Quando uma entidade possui como característica uma outra entidade, este conceito é representado no diagrama de classes UML por meio de um relacionamento entre as classes, que pode ser uma associação, agregação ou composição. Refletindo sobre esses conceitos, incluiremos no diagrama de classes UML a representação das classes, seus atributos e relacionamentos.
Este trabalho alonga os temas abordados da disciplina, com o intuito de nos ajudar a perceber a importância de reconhecermos os desafios humanos para compreensão em tema da tecnologia e ajudar-nos no desenvolvimento humano. 
 
2 CONTEÚDO 
 
2.1 	Atividade/Exercício de abstração e representação:
Descrição da atividade:
Classes para uma Loja de Assistência técnica, usando abstração e representação.
Temos as seguintes entidades: Técnico, Atendente, Cliente, Serviço, Solicitação de Serviço e Material.
O técnico possui nome, cpf, telefone. 
O Atendente possui nome e cpf.
O Cliente possui nome, cpf, endereço e telefone. 
O Serviço possui número de identificação, descrição e valor.
A Solicitação de Serviço possui número de identificação, data de solicitação, data de início, data término.
O Material possui número de identificação, descrição e valor.
 
O Cliente liga-loja e solicita a realização de um serviço.
O Atendente atende e registra a solicitação de serviço.
O Atendente define o técnico que atenderá o cliente (Atribuição do serviço) e registra a atribuição na solicitação de serviço.
O Técnico registra a data de início, realiza o serviço e registra data de conclusão.
O técnico utiliza material (produtos) na realização do serviço e registra na solicitação de serviço quais materiais utilizou. 
O cliente sabe quem realizou o serviço, quando o serviço foi realizado e quais materiais foram utilizados. 
A solicitacao de servico apresenta quem é o cliente, o técnico e materiais que foram utilizados.
O atendente usa o sistema para fazer seus registros de informações. 
O tecnico usa o sistema para fazer seus registros de informações.
A Solicitação de Serviço deve apresentar quem é o cliente, quem é o tecnico e quais materiais foram utilizados. 
A Solicitação de Serviço pode informar a data de solicitacao, quem é o cliente, quem foi o atendente, quem foi o tecnico e quais materiais foram utilizados.
Todas as entidades devem possuir um comportamento chamado “exibeInformacoes”.
Figura 01- Identificação das classes e seus atributos.
Figura 02- Pasta primária, destacarmos as classes e seus métodos especiais. 
Figura 03- Identificação classe Técnico(incluso comportamentos/estado).
Figura 04- Identificação classe Atendente(incluso comportamentos/estado).
Figura 05- Identificação classe Cliente(incluso comportamentos/estado).
Figura 06- Identificação classe Servico(incluso comportamentos/estado).
Figura 07- Identificação classe Solicitação de Serviço(incluso comportamentos/estado).
Figura 08- Identificação classe Solicitação de Serviço(incluso comportamentos/estado).
Para representar as entidades e suas relações no paradigma de orientação a objetos, vamos identificar deus comportamentos/métodos especias, de seguida excluí-los e descrever cada classe com suas características e classificar as associacões:
Parte-1: Diagrama de Classes com Generalização:
1. Pessoa (Superclasse)
 - nome: String
 - cpf: String
 - telefone: String(): void
2. Técnico (Subclasse de Pessoa)
3. Atendente (Subclasse de Pessoa)
4. Cliente (Subclasse de Pessoa)
 - endereço: String
5. Item (Superclasse)
 - numeroId: int
 - descrição: String
 - valor: double
6. Serviço (Subclasse de Item)
7. Material (Subclasse de Item)
8. Solicitação de Serviço(Classe)
 - numeroID: int
 - dataSolicitacao: Date
 - dataInicio: Date 
 - dataTermino: Date
Parte 2: Relacionamentos
- Cliente -> Solicitação de Serviço : solicita (Associação)
- Atendente -> Solicitação de Serviço : registra (Associação)
- Atendente -> Técnico : atribui serviço (Associação)
- Técnico -> Solicitação de Serviço : realiza serviço (Associação)
- Técnico -> Material : utiliza (Associação)
- Solicitação de Serviço -> Material : registra materiais utilizados (Composição)
Herança:
Atendente, Tecnico e Cliente herdam atributos e metodos de ClassPessoa.
Servicço e Material herdam atributos e metodos de ClassItem.
Herdam especificacoes dos atributos, comportamentos e colocamos em evidencia a especialização.
 
Associação: 
Tecnico, Atendente e Cliente tem dependencias entre si.
Tecnico, Atendente e Cliente estão associados a SolicitacaoServico. 
Um técnico pode trabalhar em várias solicitações de serviço.
Um atendente pode criar várias solicitações de serviço. 
Um cliente pode ter várias solicitações de serviço.
Agregação/Composição:
SolicitacaoServico agrega Item.
Uma solicitação de serviço pode ter vários serviços e utilizar vários materiais. 
SolicitacaoServico agrega Item que é composto por Material e Servico.
Uma solicitação de serviço é feita de vários servicos e varios materiais.
Agora, considere a inclusão dos relacionamentos identificados:
Associação: É uma relação genérica entre classes, onde uma instância de uma classe está relacionada a uma ou mais instâncias de outra classe.
Agregação: É um tipo de associação que indica um relacionamento todo-parte, onde uma classe é composta de uma ou mais instâncias de outra classe, mas estas instâncias podem existir independentemente da classe principal.
Composição: Também é um tipo de associação todo-parte, mas aqui as instâncias das partes só podem existir como parte da classe principal.
Para finalizar ,então temos o seguinte diagrama de classes:
Figura 09- Diagrama de Classe, e suas especificacões.
Lembre-se de que essas são inferênciascom base nos atributos fornecidos, e as associações reais dependem dos requisitos específicos do sistema que está sendo modelado. Se houver mais informações disponíveis sobre as relações entre essas entidades, poderemos definir associações mais precisas.
3 Conclusão 
 
Um Diagrama de Classes poderá ser ou não adequado para o seu projeto quando a finalidade deste diagrama alcancar os fundos de conhecimento, sendo assim, teremos de analisar algumas situações em que pode ou não fazer sentido em um diagrama de classes UML.
Desta forma, destaco a importância e a grande necessidade de buscarmos conhecimento sobre esta área tao vasta, para que possamos entender as diversas opções presentes no mercado também conhecer a necessidade para atender os negócios que já existem e que existirão. 
O estudo deste tema nossa ajudará e auxiliará na organização e soluções na organização das nossas vidas e também na área profissional enquanto construção e manutenção na craição de diagramas e projetos em linguagens de modelagem.
 
 
 
REFERÊNCIAS 
Java y BlueJ | Introducción a las Bases de la Programación | Udemy. Disponível em:. Acesso em: 12/10/ 2023.
tutorial-portuguese.pdf (bluej.org). Último acesso em 11/10/2023.
https://www.bing.com/search?q=aprender+bluej&cvid=80c3c47b2d2445cd898ee7166ba970e7&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIFCAEQ6wcyBAgCEAAyBAgDEAAyBAgEEAAyBAgFEAAyBAgGEAAyBAgHEAAyBAgIEADSAQg1MDk3ajBqOagCALACAA&FORM=ANAB01&PC=U531. Último acesso em 14/10/2023.
UML diagram software | Lucidchart. Disponivel em : Último acesso em 10/10/2023.
O Tutorial de Diagramas de Classe Ultimate para Ajudar a Modelar Facilmente os Seus Sistemas (creately.com). Último acesso em : 09/10/2023.
CADENHEAD, R.; LEMAY, L. Aprenda em 21 dias Java 2. Tradução de Daniel Vieira e Ana Beatriz Tavares. 4. ed. Rio de Janeiro: Elsevier, 2005. 
DEITEL, H. M.; DEITEL, P. J. Java: como programar. Tradução de Edson Furmankiewicz. 6. ed. São Paulo: Pearson Prentice Hall, 2007.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Tradução de Fábio Freitas da Silva et al. 2 ed. rev. atual. Rio de Janeiro: Elsevier, 2005.