Softwareové Inženýrství

Zpracování od Žolté

"Softwarový proces je po částech uspořádaná množina kroků směřujících k vytvoření nebo úpravě softwarového díla. "

• Jedná se o souhrn postupů činností, které musíme provést k vytvoření softwarového produktu
• Podle tohoto procesu pak definujeme projekty vztažené k jednotlivým zakázkám (tzv. instanciace procesu)
• Projekt můžeme rozdělit na realizaci, vývoj a řízení. Jedná se o technickou i netechnickou část, která se řídí svou metodologii.
• Projekt tím tak rozdělíme na metodologii realizace softwarového systému, metodologii vývoje a metodologii projektového řízení
• Jednotlivé kroky/činnosti v procesu můžou běžet souběžně, takže je potřeba je nějakým způsobem koordinovat
• Zároveň musí být zajištěné, že se budou dát opakovat, protože hlavní cíl je dosáhnout výsledků s konzistentní kvalitou
• Činnosti jsou zajišťované lidmi (s danými schopnostmi, znalostmi a s technickými prostředky, které jsou potřeba pro realizaci)

Úroveň je nastavená stupnicí SEI (Software Engineering Institute). Model hodnocení má 5 stupňů a nazýváme ho CMM (Capability Maturity Model)

1. Počáteční (Initial) - firma nemá definován softwarový proces a každý projekt je rešen případ od případu (ad hoc)
2. Opakovatelná (Repeatable) - firma identifikovala v jednotlivých projektech opakovatelné postupy a tyto je schopna reprodukovat v každém novém projektu
3. Definovaná (Defined) - softwarový proces je definován (a dokumentován) na základě integrace dříve identifikovaných opakovatelných kroků
4. Řízená (Managed) - na základě definovaného softwarového procesu je firma schopna jeho řízení a monitorování
5. Optimalizovaná (Optimized) - zpětnovazební informace získaná dlouhodobým procesem monitorování softwarového procesu je využita ve prospěch jeho optimalizace

Dodnes neexistuje detailně a přesně definovaný referenční softwarový proces. Nicméně lze říci, že základem téměř všech se stal tzv. vodopádový model, který je možno v různých modifikacích a rozšířeních nalézt ve většině současných přístupů.

• Dělí SW proces na 4 základní fáze:
• analýza požadavků a jejich specifikace, návrh softwarového systému, implementace (kódování), testování a udržování vtvořeného produktu
• Princip vodopádu spočívá v tom, že následující množina činností spjatá s danou fází nemůže započít dříve než skončí předchozí. Jinými slovy řečeno, výsledky předchozí fáze „vtékají“ jako vstupy do fáze následující

Nedostatky:

• Prodleva mezi zadáním projektu a vytvořením spustitelného systému je příliš dlouhá
• Výsledek závisí na úplném a korektním zadaní požadavků kladených na výsledný produkt
• Nelze odhalit výslednou kvalitu produktu danou splněním všech požadavků, dokud není výsledný softwarový systém hotov

• Jak už napovídá název, jeho nejtypičtější vlastnost je inkrementace verzí systému, které pak zahrnujou stále širší škálu funkci definovaných postupně v průběhu jeho vytváření
• V podstatě se jedná o celou řadu menších vodopádů s výrazně kratším životním cyklem, kde každý z nich odpovídá nové sadě doplňujících požadavků

• Zahrnuje do svého živostního cyklu další fáze jako je vytvoření a hodnocení prototypu ověřující funkcionalitu cílového systému, přičemž každý cyklus nabaluje další požadavky specifikované zadavatelem

• Definováný skupinou velkých firem, kterou koordinovala firma Rational
• Jedná se o disciplinovaný přístup k přiřazování úkolů a zodpovědností v rámci vývojové organizace.
• Od vodopádového modelu se liší tím, že musí dodržovat tyto principy:
• softwarový produkt je vyvíjen iteračním způsobem (na konci každé iterace je spustitelný code, který se ověří se zadavatelem a přípomínky zpracujeme do následující iterace)
• jsou spravovány požadavky na něj kladené (RUP popisuje jak požadavky vylákat od zadavatelů a jak je organizovat, monitorovat jejich změny a dokumentovat je)
• využívá se již existujících softwarových komponent (komponenty se buď propojují ad-hoc (případ od případu), nebo prostřednictvím komponentní architekury - Common Object Request Broker Architecture (COBRA), Component Object Model (COM), nebo nějaká architektura využívající internet))
• model softwarového systému je vizualizován (pomocí UML - smyslem je skrýt detaily a vytvořit kód užitím jazyka postaveného na grafickém vyjádření stavebních bloků aplikace)
• průběžně je ověřována kvalita produktu (je obsaženo ve všech aktivitách, týká se všech účastníků vývoje softwarového řešení)
• změny systému jsou řízeny (Řízení změn umožňuje zaručit, že každá změna je přijatelná a všechny změny systému jsou sledovatelné)

1. Zahájení, kde je původní myšlenka rozpracována do vize koncového produktu a je definován rámec toho, jak celý systém bude vyvíjen a implementován
2. Rozpracování je fáze věnovaná podrobné specifikaci požadavků a rozpracování architektury výsledného produktu
3. Tvorba je zaměřena na kompletní vyhotovení požadovaného díla. Výsledné programové vybavení je vytvořeno kolem navržené kostry (architektury) softwarového systému
4. Předání je závěrečnou fází, kdy vytvořený produkt je předán do užívání. Tato fáze zahrnuje i další aktivity jako je beta testování, zaškolení apod

Každá fáze může být dále rozložena do několika iterací:

Smyslem procesu je specifikovat kdo v něm vystupuje, co má vytvořit, jak to má vytvořit a kdy to má vytvořit.

• Role (pracovníci) definující chování, kompetence a zodpovědnosti jednotlivých osob(analytik, programátor, projektový manažer apod.) nebo skupiny osob spolupracujících v týmech
• Artefakty reprezentující entity, které jsou v procesu vytvářeny, modifikovány nebo zužitkovány (modely, dokumentace, zdrojové kódy apod.). Model je základním artefaktem (jedná se o zjednodušení reality, za účelem lepšího pochopení vyvíjeného systému)
• Aktivity (činnosti) prováděné pracovníky s cílem vytvořit nebo upravit artefakty (kompilace zdrojových kódů, vytvoření návrhu apod.)
• Toky (workflow) činností reprezentující posloupnosti aktivit vytvářející požadované produkty (byznys modelování, specifikace požadavků apod.)

V SW procesu jsou základní toky, jejichž výsledek je artefakt (část výsledného produktu) / model, "nahlížející na vytvářeý systém z daného pohledu abstrakce (zjednodušení)" a pak podpůrné toky, které nic nevytváří ale jsou potřeba k realizaci základního roku. Základní toky jsou:

• Byznys modelování popisující strukturu a dynamiku podniku či organizace
• Specifikace požadavků definující prostřednictvím specifikace tzv. případů použití softwarového systému jeho funkcionalitu
• Analýza a návrh zaměřené na specifikaci architektury softwarového produktu
• Implementace reprezentující vlastní tvorbu softwaru, testování komponent a jejich integraci
• Testování zaměřené na činnosti spjaté s ověřením správnosti řešení softwaru v celé jeho složitosti
• Rozmístění zabývající se problematikou konfigurace výsledného produktu na cílové počítačové infrastruktuře

Nejdůležitější podpůrné toky jsou:

• Řízení změn a konfigurací zabývající se problematikou správy jednotlivých verzí vytvářených artefaktů odrážejících vývoj změn požadavků kladených na softwarový systém
• Projektové řízení zahrnující problematiku koordinace pracovníků, zajištění a dodržení rozpočtu, aktivity plánování a kontroly dosažených výsledků. Nedílnou součástí je tzv. řízení rizik, tedy identifikace problematických situací a jejich řešení
• Prostředí a jeho správa je tok činností poskytující vývojové organizaci metodiku, nástroje a infrastrukturu podporující vývojový tým

Zpracování od Žolté

Cílem specifikace požadavků je popsat co má softwarový systém dělat prostřednictvím specifikace jeho funkcionality. Modely specifikace požadavků slouží k odsouhlasení zadání mezi vývojovým týmem a zadavatelem

Modely, které jsou tvořené v rámci této činnosti vycházejí z use case případů užití. Ty tvoří:

• Aktéři - definující uživatele či jiné systémy, kteří budou vstupovat do interakce s vyvíjeným softwarovým systémem
• Případy užití - specifikující vzory chování realizovaných softwarovým systémem. Každý případ užití lze chápat jako posloupnost vzájemně navazujících transakcí vykonaných v dialogu mezi aktérem a vlastním softwarovým systémem.

Pro vizualizaci požadavků se používají Use Case diagramy a Sekvenční diagramy.

• Use Case - popisuje vztahy mezi aktéry a jednotlivými případy použití
• Sekvenční diagramy - zobrazují inerakci objektů organizovanou podle časového hlediska

Jejich smysl je zobrazit, kdo bude se systémem operovat (aktéři) a jaké funkcionalitu (případy užití) má systém mít. Vstupem pro sestavení diagramu je byznys model (kokrétně modely podnikových procesů, vysledkem jejich analýzy je seznam požadovaných funkcí).

Do takovéhohle UML ještě musíš přidat relace. Ty jsou celkem 3: (viz druhý obrázek)

• Relace používá - <<\uses>>, vyjadřuje situace kdy jeden svénář je využíván i jinými případy užití.
• Relace rozšiřuje - <<\extends>>, vyjadřuje situaci kdy nějaký scénář rozšiřuje jiný nebo "představuje variantní průchody jím popsaným scénářem"
• Relace zobecnění/specializace/generalizace - vjadřuje vztah mezi obecným scénářem a jeho speciálním případem. Zároveň vyjdřuje dědičnost u aktérů (User se dále dělí na prodejce, účetní atd)

Instanční proměnné

• udávají vlastnosti objektů
• přístup ze třídy nebo pomocí metod get() a set()
• vznikají s objektem

Statické proměnné

• nepopisují vlastnosti objektů
• existují pouze jednou pro třídu
• mohou existovat bez objektu
• přístup ze třídy nebo pomocí jména třídy

Dobré vysvětlení i zde

• Rozdělení nějaké úlohy na dílčí části a ty spustíme zároveň
• Tím pádem nám ale vznikají nové nebezpečí programování, na které si musíme dát pozor - např. souběh
• Souběh znamená, že dílčí části přistupují k např. proměnné současně a bijou se mezi s sebou.
• Dá se to řešit, několika způsoby, nejideálněji proramovat takovým způsobem, aby k souběhu nedocházelo
• Pokud je to ovšem nezbytně nutné a k souběhu docházet bude, musíme použít např. TSL (Test and Set Lock)

• Tady ty dílčí části (definované u paralelního zpracování) ovládá jedno nějaké vlákno
• "Samostatně prováděny výpočetní, který běží v rámci jednoho procesu."
• Konkrétně v Javě dva způsoby:
  • Implementováním interfejsu Runnable.
  • Deděním z třídy Thread.
  • Oba způsoby vyžadují implementaci funkce Run() - čili co se bude ve vlákně dít.
  • Druhý způsob nabízí větší flexibilitu při handlování vícero vláken.
• 

Všechny Streamy dědí z InputStreamu, stěžejní metoda Read();

• Bytové proudy
  • FileInputStream - čte data byte po bytu.
  • Nejvíc low-level. Pokud víme, že soubor, který čteme, bude třeba text a chceme pracovat s textem, je lepší použít specifikovanější Streamy
• Znakové proudy
  • FileReader - čte data char po charu (implicitně 16bitů, ale lze specifikovat i kodování)
• Proudy s vyrovnávací pamětí
  • BufferedReader - pouze obaluje jiné InputStreamy
  • Nečte data po charu/bytu po každé z (např.) disku, místo toho je přenese do vyrovnávací paměti a pak čte
  • Díky tomu je rychlejší a efektivnější