Toward An Intelligent Requirements Tool for Modeling Use Cases and ...

5 downloads 59674 Views 931KB Size Report
Join for free. 4 Figures. Figure 6. Identifying ... can be used to model use cases and domains in ..... good end product that efficiently fulfill the user ...... The tool reuses the Parser and Name Finder tools of .
ICGST-AIML Journal, Volume 12, Issue 1, July 2012

 

Toward An Intelligent Requirements Tool for Modeling Use Cases and  Domains in Object‐Oriented Software Processes 

Azhari Gasmalla1 and Moawia Yahia2   Dept. of Computer Sciences and Information. Faculty of Sciences and Art   AlJouf University, AlJouf, Saudi Arabia  2 King Faisal University, Alhasa 31982, Saudi Arabia  [email protected], [email protected]    cripples the resulting system if done wrong. No other  Abstract  part is more difficult to rectify later" [1].  The purpose of this paper is to discuss the ability of  Carl  Zetie  stated  “No  single  factor  is  responsible  for  developing a fully automated requirements tool that  more  wasted  effort,  rework,  or  failed  projects  than  can  be  used  to  model  use  cases  and  domains  in  inadequate  requirements.”  [9]  One  study  of  factors  object‐oriented software processes. Knowledge base  challenged  projects  revealed  that  37%  of  factors  and  natural  language  processing,  some  of  artificial  related  to  problems  with  requirements,  making  intelligence  techniques,  were  utilized  in  the  requirements issues the largest single contributor to  development  of  the  proposed  tool.  The  results  problems  [3].  Ambiguity‐  where  something  can  be  indicated  the  possibility  of  developing  requirements  interpreted  in  more  than  one  way‐  is  endemic  in  tool that dispense with human intervention in many  natural  language,  and  therefore  a  considerable  cases of modeling use cases and domains. Such tool  problem for requirements that are written in natural  can  be  used  to  support  software  named  entity  language  [2].  Misinterpretation  of  requirements  is  recognizer building and vice versa.  the source of over 40% of all software defects [6].    Writing use cases‐ stories of using a system‐ is one of  Keywords:  Requirements  Tool,  Natural  Language  excellent techniques that are used to understanding,  Process,  Knowledge  base,  Named  Entity  Recognizer,  describing,  finding‐  and  more  broadly,  manage‐  Use cases, Domain Model, Computer‐Aided Software  requirements [3].   Engineering Tool.  CASE‐  Computer‐  Aided  Software  Engineering‐  tools    are  a  class  of  software  that  automates  many  1. Introduction  activities  associated  with  the  software  process‐  a  Requirements engineering is crucial to the success of  method  of  developing  software.  Tools  that  reduce  the  system  engineering  process  .It  is  an  important  the  amount  of  effort  required  to  produce  a  work  part of the systems engineering process and is cited  product  or  accomplish  some  project  milestone  have  as being critical to the success of the majority of the  substantial  benefit.  But  there’s  something  that’s  world’s  major  construction,  aerospace,  and  even more important. Tools can provide new ways of  information  system  projects  [16].  Errors  in  looking  at  software  engineering  information—ways  requirements  are  mainly  provoked  by  a  gap  existing  that  improve  the  insight  of  the  engineer  doing  the  between  users  and  system  development  process.  work.  This  leads  to  better  decisions  and  higher  This gap is due to the manual nature of requirements  software quality [5].   engineering  process  since  requirements  are  Software  developers  always  looking  for  such  CASE  informally  sought  by  analysts  from  users  who  then  tools that assist them in many different ways during  pursue  others  development  activities  according  to  the  different  development  phases  of  software,  so  what  they  understand  about  users’  needs.  One  way  that  they  understand  the  software  and  prepare  a  to  bridge  this  gab,  is  an  automatic  generation  of  good  end  product  that  efficiently  fulfill  the  user  specifications from informal requirements [17]. "The  requirements.    Obviously,  CASE  tools  provide  the  hardest  single  part  of  building  a  software  system  is  ways  that  can  fulfill  these  requirements  of  software  deciding precisely what to build. No other part of the  developers.  But,  There  is  limited  scope  for  process  conceptual  work  is  as  difficult  as  establishing  the  automation.  This  is  due  to  the  immense  diversity  of  detailed  technical  requirements,  including  all  the  software  process  and  its  need  for  human  judgment  interfaces  to  people,  to  machines,  and  to  other  and creativity [18].  software  systems.  No  other  part  of  the  work  so  1

21

ICGST-AIML Journal, Volume 12, Issue 1, July 2012

database  application  development1.  It  is  nothing  more  than  a  tool  for  visualizing  models  with  automated notations and documentations.   CaseComplete®  is  a  software  application  from  Serlio  Software  that allows  business  analysts  and  software  developers  to  create  and  manage  Use  Cases  and  Software Requirements. CaseComplete® provides the  ability  to  edit  the  textual  portion  of  use  cases  and  requirements  in  a  guided  environment  and  the  ability  to  create  various  types  of  diagrams  including  use  case  diagrams,  wireframes  of  graphical  user  interfaces,  and  flowcharts2.  The  user  needs  to  populate  specific  forms  (of  specifications),  and  then  the  tool  generates  related  models  in  text  or  figure  context.  The  contribution  of  the  paper  is  to  address  the  requirements tool that fully automated the modeling  of  use  cases  and  domains  by  adapting  techniques  from  artificial  intelligence  (AI),  in  other  words,  the  creation of an intelligent requirements tool.  The  organization  of  the  paper  is  as  follows:  the  second  section  addresses  the  methodology  of  the  proposed  tool,  and  the  third  section  explains  AI  techniques  that  can  be  applied  in  the  tool  development.  Section  four  determines  the  NER  the  proposed  tool  can  be  integrated  with  the  proposed  tool.  Section  five  addresses  address  the  relationship  between  Software  NER  and  the  proposed  tool.  Section six presents case study for the application of  the  proposed  tool.  Finally,  the  paper  includes  list  of  references and biographies.     

“Software  processes  are  complex  [13]  and,  like  all  intellectual  processes,  are  reliant  on  human  judgment.  Because  of  the  need  for  judgment  and  creativity,  attempts  to  automate  software  processes  have  met  with  limited  success.  CASE  tools  can  support some more process activities but there is no  possibility,  at  least  in  the  next  few  years,  of  more  extensive  automation  where  software  takes  over  creative  design  from  the  engineers  involved  in  the  software  process.  One  reason  why  there  is  limited  scope  for  process  automation  is  the  immense  diversity  of  software  process.  There  is  no  ideal  process  and  different  approaches  to  software  development.  Processes  have  evolved  to  exploit  the  capabilities of the people in an organization and the  specific  characteristics  of  the  systems  which  are  being  developed.  Therefore,  even  with  the  same  company,  there  may  be  many  different  processes  used for software development.”[7].  In  sum,  requirements  engineering  is  complex,  error  prone and in need of intelligent support for capturing  complete, consistent  requirement  specifications  and  guiding  the  requirements  engineering  process.  One  solution advocated by the ESPRIT Nature project is to  populate  tools  with  domain  abstractions  to  assist  requirement specification [12].   A  fully  automated  CASE  tool  is  a  CASE  tool  that  automates  all  steps  and  guideline  of  methods  of  software  process,  and  should  be  capable  to  use  the  professional  experiences  when  there  are  no  guidelines  or  apparent  activity.  Moreover,  it  must  have  a  capability  to  translate  informal  inputs  (or  fuzzy input) to formal outputs.    Each of these advances in CASE tool power will need  to  draw  heavily  on  the  field  of  AI  before  it  will  succeed.  The  domain  of  AI  has  techniques  that  can  be  used  to  deal  with  the  using  of  past  experiences,  fuzzy,  optimization  and  learning  problems.  Such  techniques include expert systems, knowledge base,  fuzzy  logic, genetic  algorithm,  and  machine  learning  –  respectively.  The  essence,  requirements  engineering can be essentially improved by applying  AI techniques [12][14] and applying AI technology in  this  area  is  appropriate  because  requirements  are  never ‘correct’ [15].  There is a large variety of existing literature that aims  to  help  articulate  the  requirements  of  users.  There  are  also  a  great  number  of  commercial  tools  available  to  build,  model  and  analyze  business  processes.  IBM’s  Rational  Software  is  a  prime  example of the huge commercial effort that has gone  into  this  field.  Despite  this,  the  requirements  gathering  process  is  still  fraught  with  difficulties.  IBM®  Rational  Rose®  Data  Modeler  offers  a  sophisticated  visual  modeling  environment  for 

2. The Tool’s Methodology  Every  tool  has  a  specific  methodology  for  designing  and modeling of the system. Every CASE tool follows  a  methodology  for  the  model  the  system.  People  who use any specific CASE tool for a longer period of  time get used with the methodology of that tool and  they  try  to  apply  the  same  methodology  for  other  projects.   The  proposed  tool  models  use  cases  and  domains. The basic procedure for defining use cases  is [3]:  1. Choose  the  system  boundary.  It  is  just  a  software  application,  the  hardware  and  application  as  a  unit,  that  plus  a  person  using it, or an entire organization?   2. Identify the primary actors‐ those that have  user goals fulfilled through using services of  the system. 

                                                             1

. See http://www01.ibm.com/software/awdtools/developer/datamodele r/ 2 . See http://www.casecomplete.com/

22

ICGST-AIML Journal, Volume 12, Issue 1, July 2012

3.

Identify  user  goals  for  each  primary  actor.  Raise  them  to  the  highest  user  goal  level  that satisfies the EBP3 guideline.  4. Define  use  cases  that  satisfy  user  goals;  name them according to their goal. Defining  use  cases  step  has  several  level  of  effort,  ranging from a few minutes to simply record  names,  up  to  weeks  to  write  fully  dressedz  versions.  In  general,  define  one  EBP‐level  use  case  for  each  user  name.  Also,  name  use cases starting with a verb.   A  domain  model  illustrates  meaningful  conceptual  classes  in  a  problem  domain;  it  is  an  important  artifact to create during object‐oriented analysis [3].  Two techniques are presented to identify conceptual  classes:  1. Use conceptual class category list.  Identify noun phrases 

If  there  is  an  actor,  a,  and  has  user  goals  that  fulfilled  through  using  services  of  the  system   then generate fact that: PrimaryActor(a)  Figure 2. Rule demonstration knowledge base for finding primary  actors. 

  Problem Statement    NER 

Named  Entities 

  3. The Tool’s Development Techniques 

  Primary Actor  Evaluation KB 

Generally,  the  tool  uses  two  artificial  intelligence  techniques,  knowledge  base  (KB)  and  natural  language processing (NLP).  In  modeling  use  cases  and  with  respect  to  the  choosing  of  the  system  boundary;  the  tool  uses  the  following domain‐specific knowledge base:  For  the  purposes  of  software  development,  the system boundary is usually chosen to be  the  software  (and  possibly  hardware)  system itself.  Figure  1  illustrates  the  representation  of  choosing‐ system‐boundary knowledge‐base:  if there is software development purposes   then generate fact that: System Boundary Is  (software) 

Primary Actors Figure 3. Finding primary actors’ data flow. 

  Sometimes, goals reveal the actors, or vice versa. So,  for  each  primary  actor,  to  identify  their  goals,  the  tool uses the following domain‐specific knowledge:  Searching  up  the  goal  hierarchy  to  find  higher  level  user  goals  that  still  satisfy  the  elementary business process (EBP) guideline,  to  get  at  the  real  intent  behind  the  action,  and  also  to  understand  the  context  of  the  goals.  Figure 4 illustrates the representation of identifying‐ user‐goals knowledge‐base.  If  there  is  an  actor,  a,  which  has  a  goal,  g,  that satisfy EBP guidelines then  generate fact that: UserGoal (a, g)   

Figure  1.  Rule  demonstration  knowledge  base  for  choosing system boundary. 

An  actor  is  something  with  behavior,  such  as  a  person  (identified  by  role),  computer  system,  or  organization.  As  for  identifying  primary  actors  and  user  goals  steps,  the  tool  uses  named  entity  recognition  (NER)  technique  to  extract  actors,  then  uses  the  following  domain‐specific  knowledge  to  evaluate each actor:  Primary  actors  have  user  goals  fulfilled  through using services of the system.  Figure  2  illustrates  the  representation  of  actor‐ evaluation  knowledge,  and  Figure  3  illustrates  the  data flow of finding primary actors step.   

Figure  4.  Rule  demonstration  knowledge  base  for  finding user goals. 

In  defining  use  cases  step,  the  tool  uses  the  same  name of the user goal to nominate the use case, and  generates a simple definition for use case.   Figure  5  illustrates  the  representation  of  defining‐ usecase knowledge‐base.    If there is an actor, a, which has a user‐goal,  ug,   then  generate fact that: UsesSystemTo (a, ug)   

                                                             3

. EBP (elementary business process) is a term from the business process engineering filed, defined as: a task performed by one person in one place at one time, in response to business event, which add measurable business value and leaves the data in a consistent state.

Figure  5.  Rule  demonstration  knowledge  base  for  defining use case. 

Finally,  in  modeling  domain,  the  tool  mixes  the  two  techniques,  mentioned  early,  in  order  to  identify 

23

ICGST-AIML Journal, Volume 12, Issue 1, July 2012

conceptual  classes.  Firstly,  the  tool  uses  NER  technique  to  implement  the  second  technique‐  identify  noun  phrases.  The  NER  receives  identified  use‐cases  and  produces  candidate  conceptual  classes.  Then  the  tool  uses  knowledge  base  technique  to  implement  the  first  technique‐  use  conceptual  class  category  list‐  to  evaluate  each  candidate  conceptual  classes  that  produced  by  NER  as shown in Figure 6. 

If  there  is  a  candidate  class,  c,  which  is  physical,  tangible  object,  specification,  design,  description,  thing,  place,  transaction,  roles  of  people,  container  of  other  thing,  thing  in  container,  other  computer,  electro‐mechanical  system  external  to  the  system,  abstract  noun  concept,  organization,  event,  process,  rule  and policy, catalog, record of finance, work,  contract,  legal  matter,  financial  instrument  and  service,  manual,  document,  reference,  paper, or book  then  generate fact that: ConceptualClass (a)   

Identified‐UseCase 

 

Figure  7.  Rule  demonstration  knowledge  base  for  conceptual classes’ evaluation. 

NER 

Candidate  Conceptual  Classes 

  5. The Tool and the Software NER  As the wealth of software knowledge in the form of  literature  increases,  there  is  a  rising  need  for  effective  natural  language  processing  tools  to  assist  in organizing and retrieving this information. To that  end,  named  entity  recognition  is  an  important  first  step  for  many  of  these  larger  information  management goals. A particular category of software  named  entity  recognizer  can  be:  CLASS,  USE  CASE,  DOMAIN MODEL, ATTRIBUTE, ASSOCIATION, etc. The  tool  plays  an  important  role  in  the  formation  of  software NER through  the provision  of  its outcomes  to  software  NER.  In  contrast,  named  entities  are  exchanged between the tool and proposed software  NER as shown in Figure 8.   

Conceptual   Classes  Evaluation 

Conceptual Classes 

 

Figure 6. Identifying conceptual classes. 

Figure  7  shows  the  representation  of  conceptual  classes’ evaluation knowledge‐base. 

 

Named  entity  recognition  (NER)  is  a  subtask  of  information  extraction  that  seeks  to  locate  and  classify  atomic  elements  in  text  into  predefined  categories  such  as  the  names  of  persons,  organizations,  locations,  expression  of  times,  monetary  values,  percentage,  etc.  Named  Entity  Recognition (NER) aims to extract and to classify rigid  designators  in  text  such  as  proper  names,  biological  species,  and  temporal  expressions.  There  has  been  growing  interest  in  this  field  of  research  since  the  early 1990s [4].  The tool reuses the Parser and Name Finder tools of  the  OpenNLP.    OpenNLP  [8]  [11]  is  a  machine  learning  based  toolkit  for  the  processing  of  natural  language  text.  It  supports  the  most  common  NLP  tasks,  such  as  tokenization,  sentence  segmentation,  part‐of‐speech  tagging,  named  entity  extraction,  chunking, parsing, and coreference resolution.     

The Tool  Software  Named  Entities 

Documents 

  4. The Tool’s NER 

Software  NER 

  Figure 8. The Tools and Software NER 

 

6. Case Study: a Library System  The  paper  presents  a  revised  version  of  library  system case study presented by Wilkinson [10].  The problem statement is:  This application will support the operations of a  technical  library  for  a  university  department.  This  includes  the  searching  for  and  lending  of  technical  library  materials,  including  books,  videos,  and  technical  journals.  All  library  items  have registration code.  Each borrower can borrow up to 10 items. Each  type  of  library  item  can  be  borrowed  for  a 

 

24

ICGST-AIML Journal, Volume 12, Issue 1, July 2012

different  period  of  time.  If  returned  after  their  due date, the employee will be charged a fine,  based on the type of item.  In  the  following  subsections,  the  paper  applies  the  proposed  tool  step  by  step  as  describe  in  as  described in sections 2‐3.  6.1 Choose the System Boundary  For  this  case  study,  the  Library  System  itself  is  the  system  under  design;  everything  outside  of  it  is  outside  the  system  boundary  including  employee,  borrower, and so on. This indicates that a purpose of  software  development  is  exist.  So,  using  Choose  System Boundary’s domain‐specific knowledge base,  the system boundary is a “Software.   6.2 Identify the Primary Actors and Their User Goals   Using the OpenNLP tool, we underline all nouns and  noun phrases in the problem statement:  This  application  will  support  the  operations  of  a  technical library for a university department. This  includes  the  searching  for  and  lending  of  technical  library  materials,  including  books,  videos,  and  technical  journals.  All  library  items  have registration code.  Each  borrower  can  borrow  up  to  10  items.  Each  type  of  library  item  can  be  borrowed  for  a  different  period  of  time.  If  returned  after  their  due  date,  the  employee  will  be  charged  a  fine,  based on the type of item.  Figure  10  shows  partial  parsing  of  the  problem  statement using the OpenNLP Parser Demo tool.  The  tool  considers  the  underlined  nouns  are  candidate  primary  actors  (or,  named  entities)  and  subjects them to primary actor’s evaluation process.  The  evaluation  process  generated  named  entity  “Employee”  as  primary  actor  because  it  has  a  user  goal  that  fulfilled  through  using  services  of  the  Library system. Employee wants accurate, fast entry,  and no borrowing errors, as bookshelf shortages are  deducted from his/her salary. Using knowledge‐base  of identifying user goals (which, investigating up the  goal hierarchy :“What is the goal of that goal?”), the  proposed  Tool  arrived  at  a  mechanism‐independent  goal: “handle a borrowing”.  6.3 Define Use Cases  In defining use case step; “Handle Borrowing” is the  name  of  the  use  case  and  the  proposed  Tool  generated    the  following  brief  format  for  Handle  Borrowing use case:  Employee  uses  the  system  to  handle  a  borrowing.  6.4 Modeling Domain  In  modeling  domain  step,  by  the  proposed  Tools  extracting  nouns  from  defined  use  cases‐  Handle  Borrowing in this case, the proposed Tool generated  “Employee” as a candidate conceptual class.     

  User  Problem Statement  Use‐Case  Modeler 

Use‐Case Models  Use‐Case Models 

Software Named Entities

Software NER 

Use‐Cases Library 

Use‐Case Model Documentations 

Domain Models 

Domain Model Documentations 

Domain  Modeler 

Domains Library 

  Figure 9. The Tools Data Flow Diagram 

 

7. Conclusion  In  software  development  process,  requirements  elicitation  is  difficult  and,  on  the  other  hand,  recognized  as  one  of  most  critical  software  development  activities.  This  is  due  to  existence  of  a  gap  between  users  and  requirements  elicitation  process  introduced  by  a  manual  handling  of  their  needs. In this paper, “and toward bridging that gap,”  we  discuss  the  ability  of  developing  a  fully  automated  scenario‐based  requirements‐elicitation  tool,  aims  to  facilitate  and  improve  requirements  elicitation process. 

25

ICGST-AIML Journal, Volume 12, Issue 1, July 2012

8. References

The  proposed  tool  starts  with  modeling  use  cases,  then  models  domains.  In  particular,  the  case  study  shows  how  the  proposed  tool  helps  users  to  model  use  cases  and  domain.  The  proposed  tool  has  succeeded  in  automating  most  of  its  operations,  while it partially failed in operations that their nature  need for human judgment. For example, consider the  automation  of  choose  system  boundary  operation;  the  system  boundary  affects  the  identification  of  primary  actors.  In  the  case  study;  in  addition  to  employee,  is  borrower  a  primary  actor  in  the  use  case Handle Borrowing?   Figure 9 shows the data flow diagram of the solution  for  the  proposed  tool.  The  answer  depends  on  the  system  boundary  of  the  system  under  design,  and  who  developer  is  primarily  designing  system  for.  So,  the operation requires human intervention from the  developer  to  decide  who  primarily  the  system  designing  for,  because  it  is  not  practical  and  inaccurate  to  extract  this  decision  from  problem  statement.  The  failure  and  difficulty  of  automating  such  tasks  is  attributed  to  incomplete  requirements  and  needs  to  natural  language  understanding  (an  immature  research  field  that  seeks  to  automate  the  task  of  information  extraction  from  software  development  specification  domain)  when  complete   requirements  are  existed.  So,  we  need  to  automate  the task of Information Extraction (IE) from problem  statements  and  software  specifications  (documents)  in  order  to  develop  a  fully  automated  requirement  tools.   

[1] [2]

[3]

[4]

[5] [6] [7] [8]

[9] [10]

[11]

[12]

[13]

[14]

[15]   Figure 10. Partial Parsing for Problem Statement

 

[16]

 

26

 

Zetie F. Brooks. No Silver Bullet. IEEE  Computer, 1987.   Francis  Chantree,  Bashar  Nuseibeh,  Anne  de  Roeck, and Alistair Willis. Identifying Nocuous  Ambiguities  in  Natural  Language  Requirements.  In  Proceedings  of  14th  IEEE  International  Requirements  Engineering  Conference (RE'06), Minneapolis, 2006.  Larman, Craig. Applying UML and Patterns: An  Introduction  to  Object‐Oriented  Analysis  and  Design and the Unified Process. Prentice Hall,  2004.   Nadeau,  David.  Semi‐Supervised  Named  Entity Recognition: Learning to Recognize 100  Entity  Types  with  Little  Supervision.  PhD  thesis, Ottawa University, 2007.   Pressman, Roger S. Software Engineering: A  Practitioner’s Approach. McGraw Hill, 2001.   Sehlhorst, Scott. Writing Unambiguous  Requirements. Tyner Blain, 2005.   Sommerville, Ian. Software Engineering.  Addison Wesley, 2001.  Wilcock, Graham .Linguistic Processing  Pipelines: Problems and Solutions. GSCL  Workshop, Potsdam, Germany, 2009.   Zetie, Carl. Forrester Research: research  report, 2006.  Wilkinson,  N.  Using  CRC  Cards,  An  Informal  Approach  to  Object‐Oriented  Development.  New York, NY: SIGS Publication, 1995.   SOURCEFORGE 2011. OpenNLP: Free Science  & Engineering Software Downloads. [online]  Available at:   [Accessed 09 October 2012].   K.  Pohl,  P.  Assenova,  R.  Doemges,  P.  Johannesson,  N.  Maiden,  V.  Plihon  ,  J.R.  Schmitt,  and  G.  Spanoudakis,  “Applying  AI  Techniques to Requirements Engineering: The  NATURE  Prototype,”  ICSE  –  Workshop  on  Research  Issues  in  the  Intersection  Between  Software  Engineering  and  Artificial  Intelligence, Sorrento, Italy, May 1994.   Wijers G.M.: Modeling Support in Information  Systems  Development,  PhD  Thesis,  Thesis  Publishers Amsterdam, 1991.  PRESSMAN, ROGER S. Software Engineering: A  Practitioner's  Approach,  6th  ed.  McGraw‐Hill.  2005.  Ian  Sommerville.  Artificial  Intelligence  and  Systems  Engineering,  Prospects  for  Artificial  Intelligence:  Proceedings  of  AISB  '93,  29  March‐2.  Scott,  W.,  and  Cook,  S.  C.  An  Architecture  for  an  Intelligent  requirements  Elicitation  and  Assessment  Assistant.  13th  Annual 

ICGST-AIML Journal, Volume 12, Issue 1, July 2012

[17]

[18]

International  Symposium  –  INCOSE  2003,  Crystal City, USA, July 1‐3.  SOMΈ,  S.,  DSSOULI,  R.,  AND  VAUCHER,  J.  1995.Toward an Automation of Requirements  Engineering  Using  Scenarios.  Journal  of  Computing and Information 2, 1110‐1132.  SOMMERVILE, I. Software Engineering, 9th ed.  Addison‐Wesley. 2011. 

Dr.  Moawia  Elfaki  Yahia  received  his  PhD  degree  in  Artificial  Intelligence  from  Putra  University,  Malaysia  in  1999.  Currently,  he  is  an  Associate  Professor  of  computer  science  at  King  Faisal  University,  Saudi  Arabia. Dr. Yahia is working as  a  member  of  editorial  board  for  many  Int.  Journal  and  member  of  program  committee  for  many  refereed conferences in computer science.  He is a  Member  of  ACM:  Association  for  Computing  Machinery,  IEEE  Computer  Society,  ACM  SIG  on  Artificial  Intelligence,  ACM  SIG  on  Knowledge  Discovery  in  Data,  Arabic  Computer  Society,  and  International Rough Sets Society. Dr. Yahia received  TWAS  award  for  Young  Scientists  in  Developing  Countries in 2006. He published over 25 articles in  international  journals  and  proceedings.  Dr.  Yahia  was  nominated  for  inclusion  in  Who's  Who  in  the  World,  28th  Edition,  2011.  His  research  interests  are  in:  intelligent  hybrid  systems,  expert  systems,  data  mining,  text  mining,  neural  networks,  rough  set theory, and intelligent information retrieval. 

   

Biographies  Azhari  Gasmalla  received  his  B.Sc.  in  computer  sciences  from  International  University  of  Africa,  and  M.Sc.  in  computer  sciences  from  University of Khartoum. Now,  he  is  PhD  student  at  University  of  Khartoum  and  working  at  AlJouf  University,  in  Saudi  Arabia,  as  a  head  of  computer  and  information  sciences  department  at  faculty  of  sciences  and  art.  His  research  interests  include  information  security,  software  analysis  and  design  and  information  extraction. 

     

   

27

Suggest Documents