análise e concepção de sistemas de informação · fazer as descrições dos casos de...

1

0HWRGRORJLD�,&21,;

$OEHUWR�0DQXHO�5RGULJXHV�GD�6LOYD3URI��'(,�,67�87/

Anál ise e Conc epç ão de Sis t em as de In form aç ão

2ACSI/Metodologias-ICONIX, Copyright, Alberto Silva

Agenda

� Enquadramento

� Visão Geral e Avisos da Metodologia Iconix

� Caso de Estudo WebDEI

– Enunciado

– Resolução

� Conclusões

2


Enquadramento

� Proposto por Doug Rosenberg (Iconix Software Engineering )– “8VH�&DVH�'ULYHQ�2EMHFW�0RGHOLQJ�ZLWK�80/��$�3UDFWLFDO�

$SSURDFK” [Rosenberg99]– www.iconixsw.com

� O ICONIX define-se como um “processo” de desenvolvimento de software simples e prático– algures entre a complexidade e abrangência do RUP e a

simplicidade e o pragmatismo do XP


Enquadramento

� É conduzido por casos de utilização

� É iterativo e incremental

� É relativamente pequeno e simples� tal como o XP, mas sem eliminar as tarefas de análise e de desenho que aquele não contempla

� Usa o UML como linguagem de modelação

� Apresenta um alto grau de rastreabilidade (WUDFHDELOLW\)

� Contempla as seguintes tarefas� Análise de requisitos� Análise e desenho preliminar � Desenho� Implementação

3


Enquadramento (nota à margem...)

� O que é a rastreabilidade?


Visão Geral

�� !�"��$#%�!�� &� ��' ��!� !��(�� "��) � �!*�� +�� !�� ,� � �� !�-�� !./��(�� ) ��!��!�!�� ) � ) � �� 0�/�� !.�� !�� ,� � ��1�� +�� 2

4


Visão Geral – Análise de Requisitos


Visão Geral – Análise de Requisitos� Diagramas de classes de alto nível (modelo de domínio)

� Identificar os objectos do mundo real e todas as relações de generalização, associação e agregação entre esses objectos.

� Desenhar o correspondente diagrama de classes de alto nível, designado por modelo de domínio.

� Protótipos de GUI, reports, navegação� Se for razoável (e.g., se for pertinente ou se houver orçamento para tal

actividade), desenvolver protótipos de interface homem-máquina (GUI), diagramas de navegação, etc. de forma que os utilizadores e clientes possam entender melhor o sistema pretendido.

� Diagramas de casos de utilização � Identificar os casos de utilização envolvidos no sistema. � Desenhar os diagramas de casos de utilização realçando os actores

envolvidos e as suas relações. � Diagramas de pacotes

� Organizar em grupos os casos de utilização. � Capturar essa organização através de diagramas de pacotes (

�/��43!�!��)

� Requisitos funcionais vs. casos de utilização� Associar requisitos funcionais aos casos de utilização e aos objectos do

domínio.

5


Visão Geral – Análise de Requisitos – AVISOS

� Na produção dos modelos de domínio– Não perder demasiado tempo com a inspecção gramatical– Não endereçar o desenho da multiplicidade demasiado cedo no

projecto– Endereçar a agregação e composição apenas na fase do desenho

detalhado� Na produção dos modelos de casos de utilização

– Não começar a escrever os casos de utilização até se conhecer bem como é que os utilizadores irão actuar

– Não passar semanas a construir modelos de casos de utilização elaborados e bem desenhados, mas a partir dos quais não é possível construir-se um adequado desenho de classes

– Não perder muito tempo em discussões sobre quando e onde usar relações “LQFOXGH” ou “H[WHQG”

– Não usar WHPSODWHV textuais de casos de utilização muito longos ou complexos


Visão Geral – Análise de Requisitos

� O ICONIX distingue explicitamente um requisito de um caso de utilização– Um caso de utilização descreve uma unidade de comportamento.– Um requisito descreve uma regra que governa o comportamento– Um caso de utilização satisfaz um ou mais requisitos funcionais.– Um requisito funcional pode ser satisfeito por um ou mais casos de

utilização.

� Há uma relação de muitos-para-muitos entre casos de utilização e requisitos– pelo que tem sentido a última actividade desta tarefa, de associação

entre estes dois conceitos.

Nota: existem outros autores que consideram, por outro lado, os casos de utilização o mecanismo ideal para se especificarem os próprios requisitos de um sistema...

6


Visão Geral – Análise e Desenho Preliminar


Visão Geral – Análise e Desenho Preliminar

� Fazer as descrições dos casos de utilização– com os cenários principais, cenários alternativos e cenários de

excepções

� Fazer a análise de robustez. Para cada caso de utilização:– Identificar um primeiro conjunto de objectos. – Usar os estereótipos de classes definidos no perfil “Processos de

Desenvolvimento de Software” especificado no UML 1.3 (ERXQGDU\, FRQWURO, e HQWLW\)

– Actualizar o diagrama de classes do modelo do domínio, com os novos objectos e atributos entretanto descobertos.

� Terminar a actualização do diagrama de classes de modo a reflectir a conclusão da fase de análise.

7


Visão Geral – Análise e Desenho Preliminar – AVISOS

� Não procurar fazer desenho detalhado nos diagramas de robustez

� Não perder tempo a tentar aperfeiçoar os diagramas de robustez à medida que o desenho evolui


Visão Geral – Desenho

8


Visão Geral – Desenho

5 Especificar o comportamento. Para cada caso de utilização:– Identificar os objectos, as mensagens trocadas entre objectos e os

métodos associados que são invocados. – Desenhar um diagrama de sequência com o texto do caso de

utilização do lado esquerdo, e informação do desenho do lado direito. Continuar a actualizar o diagrama de classes com os objectos e atributos entretanto descobertos.

– Se for relevante, usar diagrama de colaboração para ilustrar as transacções principais entre objectos.

5 Terminar o modelo estático, adicionando informação detalhada sobre o desenho (e.g., visibilidade)

5 Verificar que o desenho satisfaz todos os requisitos identificados.


Visão Geral – Desenho – AVISOS

5 Na produção dos diagramas de sequência:– Não procurar associar comportamento aos objectos antes de se ter

um ideia concreta sobre o seu significado e interesse para o sistema.

– Não começar a desenhar um diagrama de sequência antes de se ter completado o diagrama de robustez correspondente

– Não focar a atenção (e esforço) na definição de métodos “JHW” e “VHW” em detrimento dos métodos reais. (Estes métodos de acesso e alteração dos atributos podem ser facilmente gerados automaticamente a partir de uma ferramenta CASE.)

5 Na produção dos diagramas de estado– Não desenhar diagramas de estados para objectos com apenas

dois estados– Não modelar o que não é necessário modelar– Não desenhar diagramas de estados só porque se consegue

desenhá-los.

9


Visão Geral – Implementação


Visão Geral – Implementação

5 Consoante as necessidades, produzir diagramas de arquitectura– diagramas de instalação e de componentes, que apoiem a tarefa de

implementação5 Escrever e, eventualmente, gerar o código5 Realizar testes unitários e de integração5 Realizar testes de sistema e de aceitação do utilizador

10


Caso de Estudo WebDEI – Enunciado

5 O DEI ...– O DEI tem por missão promover, organizar e

realizar actividades de ensino, deactividades de investigação e dedesenvolvimento, bem como de actividadesde consultoria ligadas ao tecido social e

económico.

– O DEI é constituído por um conjunto demembros docentes, os quais se encontram organizado em áreas científicas. Cada área científica é liderada por um professor e éconstituída por vários docentes.Adicionalmente, cada área científica éresponsável explicitamente por um conjuntode disciplinas que podem ser leccionadas em diferentes licenciaturas ou outros tiposde cursos.



Arquitectura Geral…

11



5 8WLOL]DGRU�DQyQLPR: (Estes utilizadores apenas têm acesso a informação que lhes étransmitida através de documentos HTML. Estes documentos são mantidos e/ou gerados por um programa associado ao servidorHTTPD.)

– Tipicamente os documentos gerados deverão corresponder ainformação que não seja crítica/confidencial como por exemplo:consulta de informação sobre áreas científicas, sobre docentes,sobre disciplinas, etc.

5 'RFHQWH: (Estes utilizadores acedem ao sistema através de páginas HTML geradas dinamicamente (pelos servlets). )

– Podem configurar a sua página pessoal através de um formulário que lhes é apresentado.

– Podem registar eventos/notícias. – Podem receber informação periodicamente.

Utilizadores…



5 *HVWRU�(Correspondendo aos utilizadores-gestores do sistema. Estesacedem ao sistema localmente.)

– Tipicamente os gestores são responsáveis pela gestão (assuma-seapenas a operação de introdução e remoção) de utilizadores, áreas científicas, disciplinas, membros (docentes, não-docentes, outros).

– São ainda responsáveis pela gestão de todos os parâmetros deconfiguração envolvidos (e.g., definição da periodicidade do envio automático de informação de eventos/notícias).

Utilizadores…

12



Disseminação de Eventos …

6 Qualquer docente pode registar eventos/notícias. – Este regista a data em que o evento deverá ser publicado/divulgado (data

início) bem como a sua data de validade (i.e., a data a partir da qual, a sua publicação deverá cessar). Adicionalmente indica o âmbito de disseminação: se ao público geral, ou se apenas restrito aos docentes.

6 A disseminação desses eventos é realizada por duas formas complementares: – (1) numa zona específica do WebDEI através de páginas HTML ou WAP; e – (2) por envio de mensagens, sejam elas de e-mail ou sms, salvaguardando-

se necessariamente as questões de acessibilidade.

6 Apenas deverão encontrar-se publicados eventos cujo período devalidade não tenha expirado. A disseminação de informação de eventos por mensagem consiste no envio periódico de uma mensagem queresume os eventos válidos para esse período. Apenas devem serenviadas mensagens aos docentes que tenham assinalado esse desejo.


Caso de Estudo WebDEI – Resolução

Análise de Requisitos…5 Diagramas de classes de alto nível (modelo de domínio)

– Identificação das Classes7 8:9<;>= ? @�A0B/C�DEA�F G�G!H�C�B�D C�A�C�I4@�D J�C�D KL�M�F N�L�DO@�D @�L�P F N�L�DOL�Q!? F IRF S�L�S�@!G�S�@�@�M�G�F MCT P F Q�@�M�Q�F L? U!D L�G J�A�@�G!? D L�S�C�G J/S�CU�? C�D L�A�@�M�? C�G J�B/V�G!W K�D L�SU�L�X�Y�@!G J�Q!U!D G!C�G�@[Z\CU�G!@�A�F M]�D F C!GS�@�Q!U!D&? L�SU!D L�X�H�C�J/S�@�Q�L�D ]�Q!? @�D�B�D C�^ F G�G�F C�ML�P F N�L�M�? @ _%J/S�@�F M/I4@!G�? F K�L�X�H�C�@�S�@S�@�G!@�M/I4C!P IRF A�@�M�? C J�`@�A"Q�C�A�C�L�Q�? F IRF S�L�S�@�G�S�@�Q�C�M�G�U!P ? C�D F L P F KL�S�L�G�L�C ? @�Q�F S�C�G!C�Q�F L!P!@@�Q�C�MV�A�F Q�C a8:9<;>= b�Q�C�M�G�? F ? U�c S�C1B/C�DdU!A"Q�C�M$e%U!M? C�S�@�A�@�A�`�D C�G S�C�Q�@�M�? @!G J/C!G�fU�L!F G1G!@�@�M�Q�C�M�? D L�AC�D KL�M�F N�L�S�C�@�A"]�D @�L�G�Q�F @�M? c ^ F Q�L!G a�ghL�S�L�]�D @�L�Q�F @�M? c ^ F Q�L b�P F S�@�D L�S�L�B/C�DdU!A0B�D C�^ @�G�G!C�D @b�Q�C�M�G�? F ? U�c S�L�B/C�DdI4]�D F C�G�S�C�Q�@�M? @�G T B�D C�^ @�G�G!C�D @!G @�L!G�G�F G�? @�M�? @!G _ia�j<S�F Q�F C!ML�P A�@�M�? @!J/Q�L�S�L]�D @�L�Q�F @�M�? c ^ F Q�L b�D @!G4B/C�M�G!]I4@!P!@�k�B�P F Q�F ? L�A�@�M�? @�B/C�DdU!A"Q�C�Mle%U!M�? C�S�@�S�F G!Q4F B�P F ML!G fU�@B/C�S�@�A-G!@�DEP @�Q�Q�F C�ML�S�L!G�@�A"S�F ^ @�D @�M�? @�G1P F Q�@�MQ4F L? U!D L�G CU�CU�? D C!G�? F B/C!G�S�@�Q!U!D G!C!G a8:9<;>= b�D @�G4B/C�M�G!]�I4@!P!L!F MS�L�B/@�P L1B�D C�A�C�X�H�C�@�C�D KL�M�F N�L�X�H�C�S�@�S�F I4@�D G!C!G�@I4@�M�? C!G S�@Q�L�D ]�Q!? @�DEQ�F @�M�? c ^ F Q�C�@1B�D C�^ F G�G�F C�ML�P `�@�A"Q�C�A�C�B/C�D�B�D C�A�C�I4@�DOA�@�Q�L�M�F G�A�C�G�S�@S�F G�G!@�A�F ML�X�H�C�L�U�? C�A�]? F Q�L�S�@�F M�^ C�D A�L�X�H�C a m

Utilizador, Docente, GrauAcadémico, Curso, TipoCurso, AreaCientifica, Disciplina, Evento, ActividadeID, ActividadeConsultoria.

13




– Identificação das Relaçõesn Generalização (relações “pai-filho”)n Associações

– As relações de associação são captadas a partir de verbos e expressões verbais identificadas no texto, bem como a partir do conhecimento que existe sobre o domínio do problema

7 8:9<;>=�b�Q�C�M�G�? F ? U�c S�C�B/C�DdU!A"Q�C�Mle%U�M�? C�S�@�A�@�A�`�D C�G�S�C�Q�@�M�? @!G�J/C!G�fU�L!F GB/@�D&? @�MQ�@�A"L�]�D @�L�G�Q�F @�M�? c ^ F Q�L!G�a/ghL�S�L�]�D @�L�Q�F @�M? c ^ F Q�L�b�P F S�@�D L�S�L B/C�DdU!A0B�D C�^ @�G�G!C�D@�b�Q�C�M�G�? F ? U�c S�L B/C�DdI4]�D F C!G�S�C�Q�@�M�? @!G T B�D C�^ @�G�G!C�D @�G�@�L�G�G�F G�? @�M? @�Gi_iaj<S�F Q�F C�ML!P A�@�M�? @!J/Q�L�S�L�]�D @�L�Q4F @�M�? c ^ F Q�L�b�D @�GRB/C�M�G!]I4@�P @�k�BP F Q�F ? L�A�@�M�? @�B�C�DdU!AQ�C�M$e%U!M�? C�S�@�S�F G�Q�F BP F ML!G�fU�@�B/C�S�@�AoG!@�DEP @�Q�Q�F C�ML�S�L!G @�A"S�F ^ @�D @�M�? @!G�P F Q�@!MQ�F L? U!D L!GCU�CU�? D C�G�? F B/C�G�S�@�Q!U!D G!C!G�a m




14



Análise de Requisitos…5 Protótipos de GUI, reports, navegação

– O WebDEI é um sistema com interface Web, pelo que neste contexto e nesta fase pode fazer todo sentido

–n o desenho do seu modelo de navegação, n o desenho de algumas páginas HTML representativas, e ainda n a especificação de guias de estilos de desenho que deverão ser adoptados

consistentemente ao longo de todas as interfaces produzidas.

(Os detalhes desta actividade saem do âmbito desta cadeira, paramais informações consulte-se a cadeira de IHM)



Análise de Requisitos…p Diagramas de pacotes

n Organizar em grupos os casos de utilização. n Capturar essa organização através de diagramas de pacotes (

B/L�Q4q!L!K@�G)

15



Análise de Requisitos…p Diagramas de casos de utilização

n Casos definidos no pacote “Gestão do WebDEI”




n Casos definidos no pacote “Utilização do WebDEI – Anónimo”

16




n Casos definidos no pacote “Utilização do WebDEI – Docente”



Análise de Requisitos…p Requisitos funcionais vs. casos de utilização

n Associar requisitos funcionais aos casos de utilização e aos objectos do domínio.

rts\u�s vEw�x�y z { | }lz ~i� zd}$�d��h�� z ��}%zO{ z yd�l��x�y � �iz { { � y�� :� �$� z �R� y | ��$� �$}%� �d| � �� $� z }ly �$� | � �[�� l{ { � � | �$}$�R� �

rts\u$�4vEw�� &� y }lz ~$�$}l� y ��y z { x�� ~l{ �i� z �%x/� yd�i�$�$� �$�iz yd�$y z �1� | z ~i� ��i| � �1� z ��}lzE{ z yRx�y � �iz { { � y� � �� $� z �[� y | ��$� �$}l� �d| � � � �$�%�!| � | �$y$�� { � xz y | � y �

rE��u�s vt�hx�z ~$�%{�x/� }%z ��y z � z �\z y�~[� � | �i| � �\ ¡i�¢}lz�z � z ~$� � {¢� {�}l� � z ~$� z {��i�$z£� z ~i¤l�%�x�y z � | �%��z ~i� zh�l{ { | ~$�l� �$}$��<{ z ��}%z { z ¥R� ¦��%z �§� � �h��| ~i}%| � �$}$�t�$�$�$�O��dz � �$~$| { �h��}lzy z � z x� ¡i�/}%z { z ¥[�$}$�d¨ ��© �d�l| �4� ��ªR« ª$¬&�

rE��u$�4v�oxz y | � }%| � | }%�$}lz<}%��}%| { { z �d| ~$�\ ¡i�t}$� {<z � z ~i� � {�~$¡$��x�� }lzh{ z y>{ � xz y | � y�� y {��z { z {�z!| ~ �iz y | � y��l�d�d{ z �d�$~$�%�

rE��ui®Rvl�hx�z ~$�l{� {}l� � z ~i� z {%x/� }%z �£{ �[�&�dz � z y�y z �i| { � �/}%z�z � z ~$� � { �¯

17



Análise e Desenho Preliminar…p Fazer as descrições dos casos de utilização

– com os cenários principais, cenários alternativos e cenários de excepções°>±O²´³Eµ¶�·!¸/¹ º/» ¼�½>¾�¿�·�Àd» ÁÂ<Ã�Ä&±dÅ ³�Æ

: UdocenteÇ�È�É ³Ã!Ä%Ê Ë�±: Registar o anúncio de um evento (e.g., conferência, reunião, notícia)

relevante para a comunidade do DEI.Ì ³/ÍÎ/Å%Ê ±�ÏhÅ%Ê Í�Ã�Ê ÐÑ�Ò(descrição de alto nível):

1) Incluir o caso de utilização “Validar Acesso”.2) O utilizador-docente (UDocente), após a sua validação pelo sistema, recebe do sistema o

formulário "Registo de Evento". 3) O UDocente preenche adequadamente o formulário recebido, em particular especificando: o

título; uma breve descrição; um url para mais detalhes; a data de início e de fim do evento; e específica o âmbito da sua divulgação (se âmbito público, se âmbito restrito (apenas para docentes)).

4) O UDocente submete a informação introduzida.5) O sistema recebe a informação introduzida, valida-a (por exemplo, não permitindo a introdução

de dois eventos com o mesmo título), e guarda a informação numa base de dados. Para além da informação introduzida pelo UDocente, o sistema adiciona ainda a data de registo e a identificação do docente interveniente.

6) O sistema notifica adequadamente o UDocente que o registo foi realizado com sucesso.



Análise e Desenho Preliminar…p Fazer as descrições dos casos de utilização

– com os cenários principais, cenários alternativos e cenários de excepções

Ì ³/ÍÎ/Å%Ê ±£Â�Ò Ä ³/Å%ÍÑ�Ä%Ê Ë�±¢Ó�Ô&Õh³�ÆEÊ Æ�Ä Ö/Í�Ã�Ê Ñ ×/³´ÐEÅ ³�³/Í�Ã�Ø/Ê ²´³�Í�Ä&±�×/±´Ù&±dÅ\²�ÚEÒ Î/Å%Ê ±EÛ%µIdem aos passos 1), 2) e 3) do Fluxo Principal.4) O UDocente não submete o formulário num período de 1 hora, a partir do momento que o formulário foi enviado pelo sistema. O sistema aborta a transação e o caso de utilização éreinicializado.

Ì ³/ÍÎ/Å%Ê ±£Â�Ò Ä ³/Å%ÍÑ�Ä%Ê Ë�±�Ü"Ô&Ý Í�Ù&±dÅ\²´ÑÞ!ß±¢Ê Í�ËÎ�Ò Ê ×/ÑÛ%µIdem aos passos 1), 2) 3) e 4) do Fluxo Principal.5) O sistema recebe a informação introduzido, mas esta não passa nos testes de validação. 6) O sistema notifica adequadamente o UDocente que o registo não foi realizado.

18


Iconix - Implementação



Análise e Desenho Preliminar…p Fazer a análise de robustez. – A análise de robustez é uma actividade importante no ICONIX. – Foram definidos três tipos de objectos, os quais se encontram definidos no

perfil “Processos de Desenvolvimento de Software” do UML 1.3:à Objectos de fronteira/interface («boundary»)– permitem aos actores comunicarem com o sistema. – E.g., janelas, écrans, páginas Web, janelas de diálogo.à Objectos de entidade («entity»)– correspondem geralmente aos objectos identificados no modelo do domínio. – São geralmente mapeados em tabelas de bases de dadosà Objectos de controlo («control»)– funcionam como integradores entre os objectos de fronteira e os objectos de entidade– O objectivo destes objectos é conterem as regras de negócio e as políticas de

funcionamento de modo a potenciarem a independência das interfaces com os utilizadores, por um lado, e dos esquemas das bases de dados, por outr

– Terminam ocasionalmente como objectos no modelo estático; mas mais geralmente, acabam por ser convertidos em métodos de objectos de entidade ou de objectos de fronteira.

19



Análise e Desenho Preliminar…

p Fazer a análise de robustez. Sugestões:

– Desenvolver os diagramas de análise de robustez antes, ou em paralelo, com a descrição textual dos casos de utilizaçãoà de modo a influenciar a identificação dos objectos intervenientes e a escolha dos

nomes usados.

– Evitar fazer desenho detalhado nesta fase e nestes tipos de diagramasà O seu principal objectivo é captar, para cada caso de utilização, os principais objectos e respectivas relações de comunicação estabelecidas entre os mesmos.


Análise de Robustez

20




p Fazer a análise de robustez. Regras:

– Os actores podem comunicar com o sistema através de objectos fronteira.

– Os objectos fronteira comunicam apenas com actores e objectos de controlo.

– Os objectos entidade comunicam apenas com objectos de controlo.

– Os objectos de controlo comunicam apenas com objectos de fronteira e de entidade




á Casos definidos no pacote “Utilização do WebDEI – Docente”

21




p Fazer a análise de robustez. Exemplo: “Registar Evento”



Análise de Requisitos…â Diagramas de classes de alto nível (modelo de domínio)

22



Análise e Desenho Preliminar…â Terminar a actualização do diagrama de classes de modo a

reflectir a conclusão da fase de análise.



Desenho …

â O principal objectivo desta actividade é detalhar o desenho do sistema tendo em consideração a infra-estrutura computacional de suporte e a tecnologia de desenvolvimento envolvida.

Neste caso de estudo, a infra-estrutura computacional corresponde àarquitectura a quatro camadas descrita no enunciad, e a tecnologia de desenvolvimento consiste num conjunto de páginas HTML geradas dinamicamente a partir de servlets Java, numa aplicação servidormultiactividade desenvolvida em Java, e numa base de dados suportada por um gestor de base de dados não determinado à priori.

Complementarmente, o cliente web comunica com o servidor Web e os ã!ä�å\æ[ç äè ãatravés do protocolo HTTP, os ã!ä�å\æRç äè ã comunicam com o servidor Java através do protocolo RMI ( é!êæ4ê�ë�ä�ì�íè ä î�äè ïí�ð ñ ò�æ4í�ó�ê�è ô í�ò ), e o servidor comunica com o gestor de base de dados através do JDBC ( é!êæ4ê�õ�êè ê�öhê!ã!ä÷ í�ò�òä�ó!è ô æ[ô è ø ).

23



Desenho …â Especificar o comportamento

– Tal especificação é conduzida pelos casos de utilização anteriormente identificados e descritos através dos respectivos diagramas de robustez e descrições textuais.

– O comportamento de um caso de utilização especificado anteriormente através de um diagrama de robustez é agora detalhado através de um diagrama de sequência.

– Este diagrama deve usar a generalidade dos objectos e actores representados no diagrama de robustez, mas agora evidenciando o fluxo de mensagenstrocadas entre si.

â O ICONIX sugere a seguinte sequências de passos:1. Copiar o texto do caso de utilização para a margem esquerda do

diagrama de sequência.2. Adicionar os objectos de entidade.3. Adicionar os objectos de fronteira.4. Analisar e descobrir para cada objecto de controlo, em que objectos o

seu comportamento deve ser atribuído



Desenho …ù Especificar o comportamento. Exemplo

24



Desenho …â Terminar o modelo estático– adicionando informação detalhada sobre o desenho – e.g., visibilidade e padrões de desenho



Desenho …â Verificar que o desenho satisfaz todos os requisitos identificados.

â Em particular, o ICONIX sugere a aplicação da seguinte metodologia:

1. Produzir a lista de requisitos.2. Escrever o manual de utilizador do sistema, na forma de

casos de utilização.3. Iterar com os utilizadores e clientes até se conseguir “fechar”

os itens 1 e 2.4. Certificar que se consegue determinar, para cada requisito, o

seu impacto em que parte do desenho, e vice-versa.5. Determinar, a partir das diferentes partes do desenho, que

requisitos estão envolvidos.

25



Implementação …

â Não é explicitamente o foco do ICONIX...

â Mas, sugere, que consoante as necessidades– Se produzam de diagramas de arquitectura

á diagramas de instalação e de componentes, que apoiem a tarefa de implementação

– Escrever e, eventualmente, gerar o código– Realizar testes unitários e de integração– Realizar testes de sistema e de aceitação do utilizador



Implementação …

26


Conclusões

â ICONIX é um processo com uma abordagem essencialmente prática, ensina a modelar um sistema de software segundo o paradigma OO.

â É conduzido por casos, iterativo e incremental, ...

â A ideia chave do ICONIX poder-se-á identificar como “fazer (i.e. modelar) o menos possível, no mais curto período de tempo, de forma a concretizar um bom sistema”.

â Não privilegia explicitamente a utilização de vários diagramas UML, em particular não privilegia os diagramas de estado, de actividade, de arquitectura, e mesmo os diagramas de colaboração. (Diagrama de estados – classe Evento)

â Outra ideia forte do ICONIX é a distinção entre requisitos e casos de utilização.

análise e concepção de sistemas de informação · fazer as descrições dos casos de...

Documents