Модулен софтуер
За да създадем гъвкави, еволюционни и мащабируеми системи, трябва да имаме модулност, това е свойството, което ви позволява да създадете система отдолу нагоре (отдолу нагоре).
На първо място трябва да имате модулите, така че имате нужда от "архив" на модулите. След това те трябва да бъдат взаимозаменяеми, т.е. трябва да е възможно да се замени модул с друг еквивалентен модул и това се прави, като се позволява обменът на информация между модулите чрез определени интерфейси: взаимодействието на компонентите не трябва да варира, тъй като модулите варират.
Модулният софтуер открива нова парадигма на интеграция между компонентите с разработването на mashups (хибридно уеб приложение), което е да се създаде нещо, започващо от различни източници, например като се използват API, първоначално създадени за различни цели, но след това комбинирани за производство на нов продукт .
Колко прости трябва да бъдат модулите в модулна система?
Формулярите трябва да бъдат направени възможно най-опростени. Всяка компания може да управлява най-различните взаимоотношения по много различен начин (напр. Управление на персонала), но елементарните функции остават същите (напр. Ведомост). Малките модули позволяват по-голяма повторна употреба, по-малко време за разработка и постоянно развитие (например, ако отделяте потребителския интерфейс, трябва да се уверите, че той е последователен, например трябва да можете да използвате copy-paste, независимо от системата, за която е създаден този потребителски интерфейс).
Проблемът, който възниква, очевидно е как да се реализира взаимодействието между модулите. Голяма система направи възможно много информация, свързана една с друга в самата система, и също така позволи относителната информация да се управлява по еднозначен начин.
разрешения за достъп, докато с i данни са разпръснати и механизмите за удостоверяване могат да бъдат различни.
Това разлагане ни дава, в същото време, много свобода: i данни можем да ги поставим където искаме, като ги разпределяме по желание.
Интеграцията на всички компоненти, база данни, модули и интерфейси, не се случва във вакуум, а се провежда на платформа: тя е тази, която ни позволява да се интегрираме, затова е необходимо тази платформа да бъде дефинирана добре.
Това, което позволява създаването на модулни системи, е преди всичко стандарт за типа информация, която се обменя от модулите: трябва да има съответствие във възможните комуникационни потоци между модулите. Можем да имаме множество взаимозаменяеми системи за писане, ако имаме един-единствен стандарт за документа, но досега се е случило точно обратното: преобладаваща система за писане с голям брой формати на документи. Тази ситуация има две недостатъци:
- ако стандартът е свързан със система, тази система има тенденция да стане универсална,
- това има тенденция да благоприятства затварянето на пазара, защото има стандарт, който никой друг не може да генерира, така че най-разпространеният автоматично става най-силен.
Дневният ред е пример за напречно приложение към всички други приложения, тъй като трябва да има един дневен ред, поради което има смисъл да се управлява на системно ниво, а не на ниво приложение. Системата е платформата, на която стартираме приложения, чрез която ги караме да комуникират. Това ни позволява да отделим данни от приложения. Това значително опростява създаването на информационната система: можем да обединим данни на две компании по-лесно или използват различни приложения за достъп до тях данни.
Комбинирането на информационни системи е от съществено значение за процеса на сливане на компаниите. Наличието на прости формуляри улеснява обмена на информация, отколкото приемането на сложни формуляри.
Модулността често присъства вече от външна гледна точка: тази на потребителя. Всъщност той вижда системата един по един парче, тоест вижда само парчето, което използва, и го възприема като модул, отделен от останалите. Привидната модулност е първата стъпка към преминаване към реална модулност.
Това ни позволява да създаваме нови и междукомпонентни взаимодействия и услуги. Системният интерфейс става зависим от заобикалящата го среда от потребителя: системата реагира, когато потребителят се нуждае от нея, така че времето за изчакване става от съществено значение за измерване на ефективността на системата.
Важно е интерфейсът да е проектиран, започвайки от потребителя, от това, което той прави: потребителят свиква с процедурите, дори ако те са невероятни и лишени от логика.
И накрая, платформата трябва да е наясно, че е платформа: тя не само трябва да позволява изпълнението на модули, но трябва да съдържа и всички онези функции, които могат да бъдат трансверсални (например дневен ред, имейл), до които те могат да имат достъп със системните примитиви (точно както при copy-paste). За системата това може да се разглежда като
- нормални приложения, но те са от съществено значение, за да можете да се присъедините към компонентите.
- Платформа = система + напречни услуги.
Платформата не е системата и не я замества, особено ако имате различни системи (Windows, Linux, Mac ...), където междинният софтуер поема, показвайки множество системи, сякаш са едно цяло.
Следователно модулните системи трябва да имат най-малко 4 характеристики:
- формулярите трябва да са прости;
- модулите трябва да са взаимозаменяеми;
- имаме нужда от платформа, пълна с услуги, необходими за интеграция;
- интерфейсът трябва да бъде проектиран така, че да отговаря на потребителя на приложението.
Всички тези характеристики са свързани с еволюцията: модулите позволяват отделни еволюции и позволяват еволюцията на системата. От своя страна платформата и интерфейсът трябва да могат да се развиват в съответствие с протоколи и процедури.
Сподели:
Научете повече от Online Web Agency
Абонирайте се, за да получавате най-новите статии по имейл.
