інтернет банкінг

     2.2.1 Для реалізації поставлених цілей система повинна відповідати наступним функціональним вимогам:

• оформлення замовлення на дану послугу (Клієнт-Банк) - виконується адміністратором по роботі з клієнтами, коли клієнт визначився;
• формування Бази Даних клієнтів;
• формування звітів;
• здійснення пошуку по зазначених параметрах - для адміністратора:
• на прізвище клієнта;
• по номеру операції;
• на прізвище адміністратора
• можливість роботи з операціями - пошук по опису операцій;
• можливість роботи з операціями й клієнтами (для адміністратора) - додавання, видалення, редагування

 

     2.2.2 Вхідні дані:

• Анкетні дані;
• Бажання клієнта.

 

     2.2.3 Вихідні дані:

     Результати пошуку;

• Договір із клієнтом;
• Звіти;

 

     2.2.4 Вимоги до надійності.

• Передбачити контроль вхідної інформації.
• Передбачити блокування некоректних дій користувача при роботі із системою.
• Забезпечити цілісність збереженої інформації.
• Забезпечити захист від несанкціонованого доступу до інформації.

 

     2.2.5 Вимоги до складу й параметрів технічних засобів.

     Система повинна працювати на IBM сумісних комп'ютерах.

     Мінімальна  конфігурація:

1. Тип процесора Pentium III або Athlon і вище;
2. Частота процесора 333Mhz і вище;
3. Обсяг оперативного запам'ятовувального пристрою 64 Мб і більше;
4. Обсяг вільного простору на жорсткому диску 5 Mб і вище.

     Вимоги  до інформаційної й програмної сумісності.

     Система повинна працювати під управлінням сімейства операційних систем Win 32 (Windows 95, Windows 98, Windows Me, Windows 2000, Windows NT, Windows XP). Вихід у мережу Internet. 

     2.3 Вибір і обґрунтування технології проектування й інструментальних засобів розробки 

     Розробка  інформаційних систем містить у  собі кілька етапів. Однак завжди початковим етапом створення системи є вивчення, аналіз і моделювання діяльності замовника для можливого поліпшення й оптимальних методів роботи, які й будуть реалізовані в створюваному додатку.

     Перш  ніж вирішити ці проблеми й приступитися до розробки системи необхідно мати чіткий опис методології розробки, адаптованої до конкретного проекту. На основі обраної методології виробляється вибір конкретних проектних інструментів і програмних засобів.

     У своєму дипломному проекті я використовую комбінований підхід до проектування. Це найбільш популярний на сьогоднішній день спосіб формалізації вимог до системи й побудови її архітектури. Його популярність обумовлена сполученням переваг функціонального й об'єктного підходів до проектування: функціональний підхід гарний на етапі висування вимог і опису бізнес-процесів, а об'єктний - на етапі створення архітектури системи, досить зрозумілої для програміста, і подальшої реалізації проекту в об’єктно - орієнтованому середовищі програмування.

     Під моделлю ПЗ в загальному випадку розуміється формалізований опис системи ПЗ на певному рівні абстракції. Кожна модель визначає конкретний аспект системи, використовує набір діаграм і документів заданого формату, а також відбиває точку зору і є об'єктом діяльності різних людей з конкретними інтересами, ролями або завданнями. Графічні (візуальні) моделі являють собою засоби для візуалізації, опису, проектування й документування архітектури системи.

     Оскільки  складність систем підвищується, важливо  мати у своєму розпорядженні гарні методи моделювання. Хоча є багато інших факторів, від яких залежить успіх проекту, але наявність строгого стандарту мови моделювання є досить істотним. Склад моделей, використовуваних у кожному конкретному проекті, і ступінь їхньої детальності в загальному випадку залежать від наступних факторів:

• складності проектованої системи;
• необхідної повноти її опису;
• знань і навичок учасників проекту;
• часу, відведеного на проектування.

     Візуальне моделювання дуже вплинуло на розвиток ПЗ взагалі й CASE засобів зокрема. Поняття CASE (Computer Aided Software Engineering) використовується в цей час у досить широкому змісті. Первісне значення цього поняття, обмежене тільки завданнями автоматизації розробки ПЗ, у цей час набутило нового сенсу, що охоплює більшість процесів життєвого циклу ПЗ. CASE технологія являє собою сукупність методів проектування ПЗ, а так само набір інструментальних засобів, що дозволяють у наочній формі моделювати предметну область, аналізувати цю модель на всіх стадіях розробки й супроводу ПЗ й розробляти додатка відповідно до інформаційних потреб користувачів. Більшість існуючих CASE - засобів засновано на методах структурного або об’єктно - орієнтованого аналізу й проектування, що використовує специфікації у вигляді діаграм або текстів для опису зовнішніх вимог, зв'язків між моделями системи, динаміки поводження системи й архітектури програмних засобів.

     BPWin.

     BPwin є потужним інструментом для створення моделей, що дозволяють аналізувати, документувати й планувати зміни складних бізнес-процесів. BPwin пропонує засіб для збору всієї необхідної інформації про роботу підприємства й графічного зображення цієї інформації у вигляді цілісної й несуперечливої моделі. BPwin підтримує три методології: IDEF0, DFD і IDEF3, що дозволяють аналізувати ваш бізнес із трьох ключових точок зору:

     З погляду функціональності системи. У рамках методології IDEF0(Integration Definition for Function Modeling) бізнес-процес представляється у вигляді набору елементів-дій, які взаємодіють між собою, а також показуються інформаційні, людські й виробничі ресурси, споживані кожною дією.

     З погляду потоків інформації (документообігу) у системі. Діаграми DFD (Data Flow Diagramming) можуть доповнити те, що вже відбито в моделі IDEF3, оскільки вони описують потоки даних, дозволяючи простежити, яким образом відбувається обмін інформацією між бізнес-функціями усередині системи. У теж час діаграми DFD залишають без уваги взаємодія між бізнес - функціями.

     З погляду послідовності виконуваних робіт. І ще більш точну картину можна одержати, доповнивши модель діаграмами IDEF3. Цей метод привертає увагу до черговості виконання подій. В IDEF3 включені елементи логіки, що дозволяє моделювати й аналізувати альтернативні сценарії розвитку бізнесу-процесу.

     Розглянемо контекстну діаграму (Рис1):

     Керуюча інформація, що входить у блок зверху:

• Закон «Про інформатику й інформатизацію»;
• Закони, що регулюють підприємницьку діяльність.

     Вхідна  інформація, зображена у вигляді  стрілочок, що входять із лівої сторони блоку:

• Анкетні дані;
• Бажання клієнта.

     Вихідна інформація, представлена із правої сторони:

• Договір із клієнтом;
• Результати пошуку;
• Звіти.

     Механізм, що здійснює операції, представлений  стрілочками, що входять у блок знизу:

• Представник банку;
• Адміністратор.

 

     

     Рис. 1 Контекстна діаграма 

     Далі  представлена діаграма декомпозиції контекстної діаграми (Рис2). Розглянемо її більш докладно:

     

     Рис. 2 Діаграма декомпозиції процесу  

     Із  представленого малюнка видно, що відбувається декомпозиція головного процесу на 4 під процеса, для яких керуючою інформацією є Закони, що регулюють підприємницьку діяльність і Закон «Про інформатику й інформатизацію». І для всіх 4-х під процесів механізмом, що здійснює різні операції, є Адміністратор. У під процесі «Формування бази даних клієнта» операції здійснює Адміністратор.

     Розглянемо кожний під процес більш докладно:

     Оформлення  замовлення на послугу:

     Вхідна  інформація:

• Бажання клієнта;
• Анкетні дані.

     Вихідна інформація:

• Відповідь на замовлення;
• Договір із клієнтом.

     Формування  БД клієнтів:

     Вхідна  інформація:

• Анкетні дані;
• Відповідь на замовлення клієнта.

     Вихідна інформація:

• Список клієнтів.

     Здійснення  пошуку:

     Вхідна  інформація:

• Список клієнтів.

     Вихідна інформація:

• Результати пошуку.

     Формування  звітів:

     Вхідна  інформація:

• Список клієнтів;
• Анкетні дані.

     Вихідна інформація:

• Різні види звітів.

     Rational Rose.

     Rational Rose - CASE-Засіб фірми Rational Software Corporation (США) - призначено для автоматизації етапів аналізу й проектування ПЗ, а також для генерації кодів на різних мовах і випуску проектної документації. Rational Rose використовує синтез-методологію об’єктно - орієнтованого аналізу й проектування, засновану на підходах трьох провідних спеціалістів у даній області: Буча, Рамбо й Джекобсона. Розроблена ними універсальна нотація для моделювання об'єктів (UML - Unified Modeling Language) претендує на роль стандарту в області об’єктно - орієнтованого аналізу й проектування. Конкретний варіант Rational Rose визначається мовою, на якому генеруються коди програм (C++, Smalltalk, PowerBuilder, Ada, SQLWindows і ObjectPro). Основний варіант - Rational Rose/C++ - дозволяє розробляти проектну документацію у вигляді діаграм і специфікацій, а також генерувати програмні коди на З++. Крім того, Rational Rose містить засобу реінжинірингу програм, що забезпечують повторне використання програмних компонентів у нових проектах.

     У результаті розробки проекту за допомогою CASE-Засобу Rational Rose формуються наступні документи:

• діаграми класів;
• діаграми станів;
• діаграми сценаріїв;
• діаграми модулів;
• діаграми процесів;
• специфікації класів, об'єктів, атрибутів і операцій
• заготівлі текстів програм;
• модель розроблювальної програмної системи.

     Останній з перерахованих документів є текстовим файлом, що містить всю необхідну інформацію про проект (у тому числі необхідну для одержання всіх діаграм і специфікацій).  

     2.4 Постановка завдань по підсистемах 

     2.4.1 Діаграма варіантів використання (клієнт)(Рис3). 

       

     Суть  цієї діаграми зводиться до того, що клієнт виконує операцію. Це його основна  функція. Але, перед тим як її виконати, він вивчає сайт. Якщо щось не знаходить у списку операцій, він може скористатися пошуком. У кожному разі, незалежно від його «шляху», він вибирає операцію, проводить її й одержує, у підсумку, звіт. Це що стосувалося Клієнта, а далі розглянемо точку зору адміністратора (Рис 4).  
 

     Діаграма  варіантів користування (Адміністратор)(Рис4). 

       

     У функції адміністратора входить:

• Відновлення сайту. Ця функція необхідна, тому що конкуренція в даній сфері дуже більша, тому постійно потрібно поміщати нову рекламу, а так само стежити за новинками у світі інформаційних технологій;
• Створення бази даних клієнтів. Необхідно, щоб вся інформація була структурована, упорядкована, а так само для швидкого пошуку потрібної людини. База даних будується на підставі анкетних даних клієнта;
• Відновлення бази даних. Періодично може з'являтися необхідність у відновленні деяких даних, а так само додаванні нових полів.
• Здійснення пошуку клієнта на прізвище, або по статусу.
• Здійснити реєстрацію клієнта. Анкетні дані клієнта внести в базу даних.

     Формування  звітів. Кожний адміністратор повинен становити звіти для керівництва, щоб підвищити якість обслуговування, а також вчасно виявити недоліки. Звіти бувають: складання списків кількості клієнтів за день, список виконаних замовлень.