Projektowanie Oprogramowania - Software design

Projektowanie oprogramowania to proces, w którym agent tworzy specyfikację artefaktu oprogramowania przeznaczonego do realizacji celów przy użyciu zestawu pierwotnych komponentów i podlega ograniczeniom . Projektowanie oprogramowania może odnosić się do „całej czynności związanej z konceptualizacją, opracowywaniem ram, wdrażania, oddawania do użytku i ostatecznie modyfikowania złożonych systemów” lub „działalności następującej po specyfikacji wymagań, a przed programowaniem , jako… [w] stylizowanym procesie inżynierii oprogramowania. "

Projektowanie oprogramowania zwykle obejmuje rozwiązywanie problemów i planowanie rozwiązania programowego . Obejmuje to zarówno niskopoziomowe projektowanie komponentów i algorytmów, jak i wysokopoziomowe projektowanie architektury .

Przegląd

Projektowanie oprogramowania to proces przewidywania i definiowania rozwiązań programowych dla jednego lub więcej zestawów problemów. Jednym z głównych elementów projektowania oprogramowania jest analiza wymagań oprogramowania (SRA). SRA jest częścią procesu tworzenia oprogramowania, który zawiera specyfikacje używane w inżynierii oprogramowania . Jeśli oprogramowanie jest „półautomatyczne” lub skoncentrowane na użytkowniku , projektowanie oprogramowania może obejmować projektowanie doświadczeń użytkownika, tworząc scenorys, który pomaga określić te specyfikacje. Jeśli oprogramowanie jest całkowicie zautomatyzowane (co oznacza brak użytkownika lub interfejsu użytkownika ), projekt oprogramowania może być tak prosty, jak schemat blokowy lub tekst opisujący zaplanowaną sekwencję zdarzeń. Istnieją również metody półstandardowe, takie jak Unified Modeling Language i Fundamentalne koncepcje modelowania . W obu przypadkach część dokumentacji planu jest zwykle produktem projektu. Ponadto projekt oprogramowania może być niezależny od platformy lub specyficzny dla platformy , w zależności od dostępności technologii użytej do projektu.

Główna różnica między analizą oprogramowania a projektowaniem polega na tym, że wynik analizy oprogramowania składa się z mniejszych problemów do rozwiązania. Ponadto analiza nie powinna być projektowana w bardzo różny sposób dla różnych członków zespołu lub grup. W przeciwieństwie do tego, projekt skupia się na możliwościach, a zatem może i będzie istnieć wiele projektów dla tego samego problemu. W zależności od środowiska projekt często się różni, niezależnie od tego, czy jest tworzony z niezawodnych frameworków, czy implementowany z odpowiednimi wzorcami projektowymi . Przykłady projektów obejmują systemy operacyjne, strony internetowe, urządzenia mobilne, a nawet nowy paradygmat przetwarzania w chmurze.

Projektowanie oprogramowania to zarówno proces, jak i model. Proces projektowania to sekwencja kroków, które umożliwiają projektantowi opisanie wszystkich aspektów oprogramowania do budowy. Umiejętności twórcze, przeszłe doświadczenie, wyczucie tego, co sprawia, że oprogramowanie jest „dobre” oraz ogólne zaangażowanie w jakość to przykłady krytycznych czynników sukcesu kompetentnego projektu. Należy jednak zauważyć, że proces projektowania nie zawsze jest prostą procedurą; model projektowy można porównać do planów architekta domu. Rozpoczyna się od przedstawienia całości rzeczy, która ma zostać zbudowana (np. trójwymiarowe odwzorowanie domu); powoli, rzecz jest dopracowywana, aby zapewnić wskazówki dotyczące konstruowania każdego szczegółu (np. układ hydrauliczny). Podobnie model projektowy tworzony dla oprogramowania zapewnia wiele różnych widoków oprogramowania komputerowego. Podstawowe zasady projektowania umożliwiają inżynierowi oprogramowania nawigację w procesie projektowania. Davis proponuje zestaw zasad projektowania oprogramowania, które zostały zaadaptowane i rozszerzone na poniższej liście:

Proces projektowania nie powinien cierpieć z powodu „wizji tunelowej”. Dobry projektant powinien rozważyć alternatywne podejścia, oceniając każde w oparciu o wymagania problemu, dostępne zasoby do wykonania pracy.
Projekt powinien być możliwy do prześledzenia do modelu analitycznego. Ponieważ pojedynczy element modelu projektu często można prześledzić wstecz do wielu wymagań, konieczne jest posiadanie środków do śledzenia, w jaki sposób wymagania zostały spełnione przez model projektu.
Projekt nie powinien wymyślać koła na nowo. Systemy są konstruowane przy użyciu zestawu wzorców projektowych, z których wiele prawdopodobnie napotkano już wcześniej. Te wzory powinny być zawsze wybierane jako alternatywa dla ponownego odkrywania. Czasu jest mało, a zasoby ograniczone; czas projektowania należy zainwestować w reprezentowanie (naprawdę nowych) pomysłów poprzez integrację wzorców, które już istnieją (w stosownych przypadkach).
Projekt powinien „zminimalizować dystans intelektualny” między oprogramowaniem a problemem, jaki istnieje w świecie rzeczywistym. Oznacza to, że struktura projektu oprogramowania powinna, o ile to możliwe, naśladować strukturę domeny problemu.
Projekt powinien wykazywać jednolitość i integrację. Wzór jest jednolity, jeśli wydaje się w pełni spójny. Aby osiągnąć ten wynik, przed rozpoczęciem prac projektowych należy określić zasady stylu i formatu dla zespołu projektowego. Projekt jest zintegrowany, jeśli zadbano o zdefiniowanie interfejsów między komponentami projektu.
Projekt powinien być tak skonstruowany, aby uwzględniał zmiany. Koncepcje projektowe omówione w następnej sekcji umożliwiają projektowi osiągnięcie tej zasady.
Konstrukcja powinna być tak skonstruowana, aby degradowała się delikatnie, nawet w przypadku napotkania nieprawidłowych danych, zdarzeń lub warunków pracy. Dobrze zaprojektowane oprogramowanie nigdy nie powinno „bombardować”; powinien być zaprojektowany tak, aby uwzględniał nietypowe okoliczności, a jeśli musi zakończyć przetwarzanie, powinien to zrobić w sposób pełen wdzięku.
Projektowanie to nie kodowanie, kodowanie nie jest projektowaniem. Nawet jeśli szczegółowe projekty proceduralne są tworzone dla komponentów programu, poziom abstrakcji modelu projektu jest wyższy niż kod źródłowy. Jedyne decyzje projektowe podejmowane na poziomie kodowania powinny dotyczyć drobnych szczegółów implementacji, które umożliwiają zakodowanie projektu proceduralnego.
Projekt powinien być oceniany pod kątem jakości w trakcie tworzenia, a nie po fakcie. Dostępnych jest wiele koncepcji projektowych i środków projektowych, aby pomóc projektantowi w ocenie jakości w całym procesie rozwoju.
Projekt powinien zostać poddany przeglądowi, aby zminimalizować błędy koncepcyjne (semantyczne). Czasami pojawia się tendencja do skupiania się na drobiazgach podczas przeglądu projektu, pomijając las dla drzew. Zespół projektowy powinien upewnić się, że główne elementy koncepcyjne projektu (pominięcia, niejednoznaczność, niespójność) zostały uwzględnione przed zajęciem się składnią modelu projektowego.

Koncepcje projektowe

Koncepcje projektowe zapewniają projektantowi oprogramowania podstawę, na podstawie której można zastosować bardziej wyrafinowane metody. Ewoluował zestaw podstawowych koncepcji projektowych. Są to:

Abstrakcja – Abstrakcja jest procesem lub wynikiem uogólniania poprzez zmniejszenie zawartości informacyjnej pojęcia lub obserwowalnego zjawiska, zwykle w celu zachowania tylko informacji, które są istotne dla określonego celu. Jest to akt Reprezentowania podstawowych funkcji bez uwzględniania szczegółów tła lub wyjaśnień.
Wyrafinowanie - Jest to proces opracowania. Hierarchia jest tworzona przez dekompozycję makroskopowej instrukcji funkcji w sposób stopniowy, aż do osiągnięcia instrukcji języka programowania. W każdym kroku jedna lub kilka instrukcji danego programu jest rozkładanych na bardziej szczegółowe instrukcje. Abstrakcja i Wyrafinowanie to pojęcia uzupełniające się.
Modułowość - Architektura oprogramowania jest podzielona na komponenty zwane modułami.
Architektura oprogramowania — odnosi się do ogólnej struktury oprogramowania i sposobów, w jakie ta struktura zapewnia integralność koncepcyjną systemu. Dobra architektura oprogramowania zapewni dobry zwrot z inwestycji w odniesieniu do pożądanego wyniku projektu, np. pod względem wydajności, jakości, harmonogramu i kosztów.
Hierarchia kontroli — struktura programu, która reprezentuje organizację komponentu programu i implikuje hierarchię kontroli.
Podział strukturalny — Strukturę programu można podzielić na poziome i pionowe. Podziały poziome definiują oddzielne gałęzie hierarchii modułowej dla każdej głównej funkcji programu. Podział pionowy sugeruje, że kontrola i praca powinny być rozłożone od góry do dołu w strukturze programu.
Struktura danych - Jest to reprezentacja logicznego związku między poszczególnymi elementami danych.
Procedura oprogramowania - Koncentruje się na przetwarzaniu każdego modułu z osobna.
Ukrywanie informacji — moduły powinny być określone i zaprojektowane tak, aby informacje zawarte w module były niedostępne dla innych modułów, które nie potrzebują takich informacji.

W swoim modelu obiektowym Grady Booch wymienia abstrakcję, enkapsulację, modularyzację i hierarchię jako podstawowe zasady projektowania oprogramowania. Akronim PHAME (Zasady hierarchii, abstrakcji, modularyzacji i enkapsulacji) jest czasami używany w odniesieniu do tych czterech podstawowych zasad.

Rozważania projektowe

Podczas projektowania oprogramowania należy wziąć pod uwagę wiele aspektów. Waga każdego zagadnienia powinna odzwierciedlać cele i oczekiwania, które ma spełniać tworzone oprogramowanie. Niektóre z tych aspektów to:

Zgodność — oprogramowanie może współpracować z innymi produktami zaprojektowanymi do współdziałania z innym produktem. Na przykład oprogramowanie może być wstecznie kompatybilne ze starszą wersją samego siebie.
Rozszerzalność — do oprogramowania można dodawać nowe możliwości bez większych zmian w podstawowej architekturze.
Modułowość - powstałe oprogramowanie składa się z dobrze zdefiniowanych, niezależnych komponentów, co prowadzi do lepszej konserwacji. Komponenty mogą być następnie wdrażane i testowane oddzielnie, zanim zostaną zintegrowane w celu utworzenia pożądanego systemu oprogramowania. Pozwala to na podział pracy w projekcie wytwarzania oprogramowania.
Odporność na awarie — oprogramowanie jest odporne na awarie komponentów i może je naprawić.
Łatwość utrzymania — miara tego, jak łatwo można dokonać poprawek błędów lub modyfikacji funkcjonalnych. Wysoka łatwość konserwacji może być wynikiem modułowości i rozszerzalności.
Niezawodność ( trwałość oprogramowania ) — oprogramowanie jest w stanie wykonać wymaganą funkcję w określonych warunkach przez określony czas.
Ponowne - Możliwość korzystania z niektórych lub wszystkich aspektów oprogramowania wcześniej istniejącej w innych projektach z małą lub bez modyfikacji.
Solidność — oprogramowanie może działać w warunkach stresu lub tolerować nieprzewidywalne lub nieprawidłowe dane wejściowe. Na przykład może być zaprojektowany tak, aby był odporny na warunki małej ilości pamięci.
Bezpieczeństwo — oprogramowanie jest w stanie wytrzymać i oprzeć się wrogim działaniom i wpływom.
Użyteczność — interfejs użytkownika oprogramowaniamusi być użyteczny dla docelowego użytkownika/odbiorców. Domyślne wartości parametrów muszą być wybrane tak, aby były dobrym wyborem dla większości użytkowników.
Wydajność — oprogramowanie wykonuje swoje zadania w akceptowalnym dla użytkownika czasie i nie wymaga zbyt dużej ilości pamięci.
Przenośność — oprogramowanie powinno nadawać się do użytku w wielu różnych warunkach i środowiskach.
Skalowalność — oprogramowanie dobrze dostosowuje się do rosnącej ilości danych lub dodanych funkcji lub liczby użytkowników.

Język modelowania

Język modelowania jest jakiś sztuczny język, który może być używany do wyrażania informacji, wiedzy lub systemy w strukturze, która jest wyznaczona przez spójny zestaw zasad. Zasady te służą do interpretacji elementów konstrukcji. Język modelowania może być graficzny lub tekstowy. Przykładami języków modelowania graficznego do projektowania oprogramowania są:

Opis architektury język (ADL) to język używany do opisania i reprezentuje architekturę oprogramowania o systemie oprogramowania .
Notacja modelowania procesów biznesowych (BPMN) jest przykładem języka modelowania procesów .
EXPRESS i EXPRESS-G (ISO 10303-11) to międzynarodowy standardowy język modelowania danych ogólnego przeznaczenia .
Extended Enterprise Modeling Language (EEML) jest powszechnie używany do modelowania procesów biznesowych na wielu warstwach.
Schematy blokowe to schematyczne reprezentacje algorytmów lub innych procesów krokowych.
Fundamental Modeling Concepts (FMC) to język modelowania dla systemów intensywnie korzystających z oprogramowania.
IDEF to rodzina języków modelowania, z których najbardziej godne uwagi to IDEF0 do modelowania funkcjonalnego, IDEF1X do modelowania informacji i IDEF5 do modelowania ontologii .
Jackson Structured Programming (JSP) to metoda programowania strukturalnego oparta na zależnościach między strukturą strumienia danych a strukturą programu.
LePUS3 to zorientowany obiektowo wizualny język opisu projektu i formalny język specyfikacji , który jest odpowiedni przede wszystkim do modelowania dużych programów zorientowanych obiektowo ( Java , C++ , C# ) i wzorców projektowych .
Unified Modeling Language (UML) to ogólny język modelowania służący do opisu oprogramowania zarówno pod względem strukturalnym, jak i behawioralnym. Posiada notację graficzną i pozwala na rozszerzenie o Profil (UML) .
Alloy (język specyfikacji) to język specyfikacji ogólnego przeznaczenia do wyrażania złożonych ograniczeń strukturalnych i zachowania w systemie oprogramowania. Zapewnia zwięzłą bazę językową opartą na logice relacyjnej pierwszego rzędu.
Systems Modeling Language (SysML) to nowy język modelowania ogólnego przeznaczenia do inżynierii systemów.
Modelowanie zorientowane na usługi (SOMF)

Wzorce projektowe

Projektant oprogramowania lub architekt może zidentyfikować problem projektowy, który był odwiedzany i być może nawet rozwiązany przez innych w przeszłości. Szablon lub wzorzec opisujący rozwiązanie typowego problemu jest znany jako wzorzec projektowy . Ponowne wykorzystanie takich wzorców może przyspieszyć proces tworzenia oprogramowania.

Technika

Trudność w używaniu terminu „projekt” w odniesieniu do oprogramowania polega na tym, że w pewnym sensie kod źródłowy programu jest projektem tworzonego przez niego programu. W takim stopniu, w jakim jest to prawdą, „projektowanie oprogramowania” odnosi się do projektu projektu. Edsger W. Dijkstra określił to nawarstwianie poziomów semantycznych jako „radykalną nowość” programowania komputerowego, a Donald Knuth wykorzystał swoje doświadczenie w pisaniu TeX-a, aby opisać daremność prób zaprojektowania programu przed jego wdrożeniem:

T _E X byłby kompletną porażką, gdybym tylko go określił i nie uczestniczył w pełni w jego początkowej implementacji. Proces wdrażania nieustannie prowadził mnie do nieoczekiwanych pytań i nowych spostrzeżeń na temat tego, jak można ulepszyć oryginalne specyfikacje.

Stosowanie

Dokumentacja projektowa oprogramowania może być przeglądana lub prezentowana w celu umożliwienia dostosowania ograniczeń, specyfikacji, a nawet wymagań przed programowaniem komputerowym . Przeprojektowanie może nastąpić po przeglądzie zaprogramowanej symulacji lub prototypu . Możliwe jest projektowanie oprogramowania w procesie programowania, bez planu lub analizy wymagań, ale w przypadku bardziej złożonych projektów nie byłoby to uważane za wykonalne. Oddzielny projekt przed programowaniem umożliwia multidyscyplinarnym projektantom i ekspertom merytorycznym (MŚP) współpracę z wysoko wykwalifikowanymi programistami w zakresie oprogramowania, które jest zarówno użyteczne, jak i sprawne technicznie.

Zobacz też

Bibliografia

^ Roger S. Pressman (2001). Inżynieria oprogramowania: podejście praktyka . McGraw-Hill. Numer ISBN 0-07-365578-3.

Languages

In other projects