Téma 2: Nástroje pro analýzu systému a návrh SW produktu

Počítačem podporovaná výroba

Téma 2: Nástroje pro analýzu systému a návrh SW produktu 2.1 Co je to SYSTÉM? Pracovní definice pro naše potřeby může znít: SYSTÉM je množina vzájemně souvisejících objektů či komponent, na kterou nahlížíme jako na celek a která byla vytvořena pro určitý účel; systém je ohraničený a to co je vně této hranice se nazývá okolí, s nímž systém interaguje prostřednictvím svých rozhraní.

Základní úlohou analýzy systému je nacházení faktů, zákonitostí a omezení v systému. Prvním úkolem při analýze je stanovení hranice systému. Softwarový produkt je pak správním či řídicím systémem nad systémem základním (pozor na směšování pojmů!)

2.2 Metody modelování výrobního systému Dva možné přístupy a) shora dolů (top-down) založeno na specializaci: začíná na úrovni komplexního systému, který postupně dekomponuje na subsystémy, které jsou dále dekompovány atd. Analytický proces je zobrazitelný stromovou strukturou s originálním systémem v kořeni. b) zdola nahoru (bottom-up) založeno na generalizaci: začíná identifikací a analýzou několika jednoduchých struktur, snaží se najít jejich společné charakteristiky a chování a zobecnit je tak, aby původní byly jejich specielními případy. Nástroje pro analýzu systému a návrh SW produktu - str. 1


Nástroje pro analýzu systému a návrh SW produktu - str. 2

Počítačem podporovaná výroba à Objektově orientovaná analýza. Přístup "zdola nahoru", jehož základní myšlenkou je zobecňování. Začíná se z konkrétní části systému, která se analyzuje a popíše. V dalších částech se pak hledají společné rysy, z nichž se odvozují obecné zákonitosti. Výhodou je možnost rychlého paralelního vývoje prototypového software, soulad s moderními prostředky softwarového vývoje. à Strukturovaná analýza. Klasický postup "shora dolů". Chápe systém jako celek a postupně ho dekomponuje na jednodušší části. Je metodicky velmi dobře zvládnut. Nevýhodou je absence možnosti ukončit předčasně analýzu a implementovat konkrétní část systému. Typickým příkladem je metoda SSADM (Structured Systems Analysis and Design Method).

2.3 Definice systému a jeho komponent

1. Samostatné komponenty

5. Rozhraní

2. Vzájemně související komponenty

6. Vstup

3. Hranice systému

7. Výstup

4. Okolí

8. Omezení 9. Účel Nástroje pro analýzu systému a návrh SW produktu - str. 3

Počítačem podporovaná výroba Rozhraní poskytuje • Zabezpeční - ochrána systému před nežádoucími průniky zvenčí • Filtrace nežádoucích dat na vstupu do systému, výstup pouze žádoucích dat • Kódování a dekódování výstupních a vstupních zpráv • Detekce a oprava chyb při interakci s okolím • Vyrovnávací vrstva mezi systémem a okolím, takže systém i okolí mohou pracovat asynchronně • Seskupování dat a jejich transformace do požadované úrovně detailu a formátu

2.4 Analýza systému Obvyklým předmětem analýzy je a) existující systém, jehož struktura a funkce nejsou zřejmé zákazníkovi a řešiteli, případně zákazník neumí strukturu a chování systému řešiteli vysvětlit, b) neexistující systém, o němž má zákazník nepříliš přesnou představu a neumí požadované funkce řešiteli vysvětlit. Inženýrská praxe řeší v naprosté většině případů realizaci takto formulovaných systémů. Produktem analýzy je specifikační dokument, který má v praxi mnoho různých forem a názvů (Projektová dokumentace, Funkční specifikace, Vnější specifikace, Specifikace návrhu, Dokument požadavků aj.) Specifikační dokument je závazným podkladem pro návrh a realizaci systému a má často i právní platnost, neboť se stává přílohou obchodní smlouvy jako doklad, který přesně definuje předmět a rozsah plnění.


Počítačem podporovaná výroba Specifikační dokument stanovuje • obsah řešení, požadovaný výsledek • podrobně dokumentovaný cílový stav v takové podobě, aby bylo možné posoudit, zda implementace uvedeného stavu dosáhla • důležité průvodní parametry spojené s řešením a provozem, např. cena, přínos (nejen finanční), plánování, dosažený výkon, .. Výsledek řešení je zachycen ve formě technické a uživatelské dokumentace. Rozsáhlé programové celky určené pro počítačovou podporu výroby vytvářejí společně s dalšími komponentami komplexnější systémy, integrující podnikové aplikace - např. informační systémy ERP, CRM, SCM, řídicí systémy, atd. Nový systém nahrazuje často stávající systém. Při náhradě požadujeme, aby nový systém splnil dva základní požadavky: • Systém porozumí všem relevantním vnějším podnětům (příkazům, zprávám), které vnímal i dřívější systém; • Systém zaručí stejné a nově požadované funkce a chování a bude mít přinejmenším shodnou odezvu na podněty z okolí. Návrh nového systému nejvíce usnadní dva druhy poznatků: • Znalost prostředí, v němž bude systém pracovat, nám pomáhá odhalit, jaké vlivy mohou působit na systém. • Znalost struktury systému a funkcí elementárních částí pomáhá při poznání a pochopení logiky těch funkcí systému, které jsou "viditelné" v okolí systému.


Počítačem podporovaná výroba Z předchozích úvah plyne, že pro pochopení a návrh systému je vhodné nalézt nebo vytvořit rozklad systému, který se co nejvíce přiblíží přirozené dekompozici reálného systému. Při analýze budeme vnímat systémy jako soustavy, složené z jednodušších systémů a prvků, které mají určitou strukturu a chování. Vytvořená dekompozice (sada dekompozic) bude základem specifikace nového systému. V softwarovém inženýrství se často používají pojmy metoda a metodologie. Metoda je procedura nebo technika, technologický postup, pomocí něhož se provede (podpoří, zajistí) nějaká významná část životního cyklu softwaru. Příkladem jsou postupy používané pro definici požadavků, pro navrhování databází, návrh programů, testovací techniky aj. Metody používají různé nástroje. Jedná se o textové a grafické editory, formuláře atd. na různé úrovni - nástroje mohou být univerzálně orientované (běžné textové a grafické editory), nebo jsou přizpůsobeny pro danou metodu a metodologii (specializované visuální editory, apod.). Metodologie je kolekce metod, které jsou vybrány na základě společné filosofie a společně podporují větší část (obvykle několik etap) životního cyklu programu. Příkladem jsou např. metodologie SSADM (Velká Británie), Moderní strukturovaná analýza (E.Yourdon, USA), aj.



Téma 3: Použití SSADM pro návrh systému SSADM bylo navrženo firmou Learmonth and Burchett Management Systems Plc. (UK) na základě vítězství v tendru vyhlášeném CCTA (Central Computing and Telecommunications Agency) a zavedeno r. 1981 jako standardní metodologie pro vládní IT projekty v UK1. Hlavní aplikační doménou SSADM je návrh informačních systémů. Proto se zaměřuje zejména na datové toky, datové modely a (jako specialitu) životní cykly entit. Důraz je kladen na detailní a strukturovaný přístup v adekvátní etapě vývojového V-modelu, používá řadu nástrojů pro zachycení a vizualizaci detailů na každé úrovni návrhu. Strategy Coverage of SSADM Maintenance and review

Feasibility

User requirements

Production

Functional specification

Acceptance testing

Integration and testing

Design

Construction

1

V dalších letech byla metodologie postupně vylepšována a poslední ver. 4 byla uvolněna v r.1990. SSADM je otevřeným standardem, je volně dostupná i pro komerční využití a je široce využívána i pro výukové účely. Od r. 2001 se CCTA stala součástí Office of Government Commerce (OGC) of UK Government a další vývoj SSADM bude pod OGC.

Použití SSADM pro návrh systému - str. 7

Počítačem podporovaná výroba Požadavky na nový systém jsou analyzovány spolu s poznatky o současném stavu a jsou vytipována omezení, za kterých bude nový systém provozován. 1. Tyto znalosti spolu s požadavky uživatelů se použijí k návrhu základních rysů systému. 2. Na základě tohoto popisu se provede detailní analýza všech požadavků, zahrnující modelování systému z různých hledisek. Tyto modely jsou vzájemně kontrolovány na konzistenci, přičemž některé funkce systému mohou být pro názornost prototypovány. 3. Zvolí se finální platforma pro implementaci systému a provede detailní logický návrh systému a návrh uživatelského rozhraní. 4. Kompletní logická specifikace systému se implemetuje v konkrétním SW/HW prostředí. Jednotlivé kroky jsou popsány z hlediska cílů, zúčastněných složek, prováděných aktivit, vstupních podmínek (prerekvizit), výstupů a použitých technik.

3.1 Hlavní složky SSADM 1. Strukturální model (Structural Model) - soubor modulů, z nichž každý zahrnuje jednu až dvě etapy, přičemž každá etapa je určena posloupností kroků spolu s vstupy/výstupy a dalšími závislostmi 2. Techniky a postupy (Techniques and Procedures) - jak postupovat v jednotlivých krocích 3. Slovník SSADM (Dictionary) - definuje veškeré výstupy metody a příslušná kvalitativní kritéria 4. Projektové postupy (Project Procedures) - další prováděné relevantní aktivity, které však nejsou přímo součástí SSADM Použití SSADM pro návrh systému - str. 8


Ad 1. Strukturální model SSADM - fáze (etapy) a kroky Stage 0 Feasibility

Feasibility Study M odule

Stage 1 Investigation of current environm ent

Stage 2 Business System Options

Requirem ents Analysis M odule

Stage 3 Definition of Requirem ents Requirem ents Specification M odule

Stage 4 Technical System Options

Stage 5 Logical Design

Logical System Specification M odule

Stage 6 Physical Design

Physical D esign M odule


Počítačem podporovaná výroba Ad 2. SSADM kombinuje tři základní techniky: • Modelování logických datových struktur (Logical Data Modeling) – proces identifikace, modelování a dokumentace požadavků na datové struktury systému. Data jsou separována do entit2, které ukazují, jaká informace je ukládána a jaké jsou vzájemné relace • Modelování datových toků (Data Flow Modeling) – proces identifikace, modelování a dokumentace toho, jak jsou data předávána v systému, jaké procesy je zpracovávají, jak jsou ukládána, co je zdrojem a příjemcem dat. • Modelování chování entit (Entity Behavior Modeling) – proces identifikace, modelování a dokumentace toho, jaké události ovlivňují jednotlivé entity, v jakých posloupnostech tyto události nastávají a jak ovlivňují životní cykly entit. Tyto tři techniky se vyájemně doplňují, referencují a jako celek zajišťují úplnost a korektnost analýzy celého systému. Techniky a postupy v SSADM popisují, jak mohou být jednotlivé aspekty systému modelovány a jak má být potřebná informace shromažďována a dávána do souvislostí Techniky používající diagramy: • logický datový model, • model toku dat, • E/E model (entita/událost) • I/O struktury • model uživatelského rozhraní • modely přístupu k datům a • logický návrh databáze.

2

entita je něco, co má význam pro systém a o čem se má uchovávat informace (Knihovní systém: knihy, čtenáři, výpujčky, rezervace, pokuty; Personalistika: zaměstnansti, pracovní místa, dovednosti)


Počítačem podporovaná výroba Další techniky a postupy: • analýza relačních dat • definice požadavků • definice funkcí systému; • formulace variant; • prototyp specifikace. Ad 3. SSADM Slovník SSADM slovník uvádí seznam všech výstupů SSADM, popisuje jejich kvalitativní úroveň, informační obsah a vzájemné vztahy. Ad 4. Projektové postupy Projektové práce související se SSADM zahrnují správu projektu, kvalitativní kriteria, kapacitní plánování, testování aj.

3.2 Příklad začlenění SSADM metodologie do vývojového procesu podniku


Počítačem podporovaná výroba Fáze projektu

Hlavní kroky

Etapa SSADM

Project Request

Initial Request Statement (IRS)

-

Feasibility Study

Feasibility Study (FS)

Stage 0 (Feasibility)

System Analysis and Design

System Analysis (SA)

Stage 1 (Investigation of Current Environment) Stage 2 (Business System Options) Stage 3 (Definition of Requirements) Stage 4 (Technical System Options)

Implementation

Logical System Design (LSD)

Stage 5 (Logical Design)

Physical System Design (PSD)

Stage 6 (Physical Design)

Programming Development (PD)

-

System Integration & Testing (SI&T)

-

User Acceptance Testing & Training (UA&T)

-

System Installation & Production (SI&P)

-

Project Evaluation Review

-

Post Implementation Review Post Implementation Review nad Maintenace Maintenance -



Téma 4: Struktura SSADM Struktura SSADM je založena na konceptu modulů. Obvyklou posloupnost řešení shrnuje tabulka: Module

Input

Product

Feasibility study module

none

Feasibility report

Requirements analysis module

Feasibility report

Analysis of requirements

Requirements specification module

Analysis of requirements

Requirements specification

Logical system specification module

Requirements specification

Logical system specification

Physical design module

Logical system specification

Physical system specification

4.1 Popis modulů SSADM 4.1.1 FEASIBILITY STUDY MODULE Studie proveditelnosti, SSADM Stage 0. Účel: • rozhodnout o tom, zda je projekt realný; • definovat zhruba rámec a cíle projektu. Otázky, na které odpovídá: • Je reálné, že systém splní očekávané cíle? • Vyváží přínosy systému vynaložené náklady? • Jak rozsáhlý systém je potřeba? Výstupy: • studie proveditelnosti Struktura SSADM - str. 13


4.1.2 REQUIREMENTS ANALYSIS MODULE Analýza požadavků, SSADM Stage 1 a 2 Účel: • přehledově definovat požadavky na nový systém na základě stávajícího systému (Stage 1) • dokumentovat další požadavky uživatele na nový systém (Stage 2) Přehled: Požadavky jsou analyzovány v následujících posloupnostech: • analýza současné funkce, dat a kategorií uživatelů systému; • zjištění požadavků na nový systém; • formulace základních rysů systému. Výstupy: • analýza požadavků

4.1.3 REQUIREMENTS SPECIFICATION MODULE Specifikace požadavků, SSADM Stage 3. Účel: • detailně specifikovat požadavky na nový systém Přehled: V tomto modulu se konkretizují a kvantifikují požadavky na systém, vzešlé z předchozí analýzy. Data and funkce jsou popsány použitím několika technik z různých hledisek. Někdy se využívá prototypování (zejména uživatelského rozhraní). Výstupy: • konečné • katalog dat (Data Catalogue); • katolog požadavků (Requirements Catalogue); • specifikace zpracování (Processing Specification).

Struktura SSADM - str. 14

Počítačem podporovaná výroba • mezi-výstupy • DFD požadovaného systému (Required System Data Flow Model); • E/E matice (Event/Entity Matrix); • relační model (Relational Data Analysis Working Paper); • uživatelské role v systému (User Roles); • prototypy (Prototyping Products).

4.1.4 LOGICAL SYSTEM SPECIFICATION MODULE Logický návrh systému, SSADM Stage 4 a 5 Cíl: • popsat z technického hlediska prostředí nového systému (Stage 4); • poskytnout detailní specifikaci průběhu zpracování v systému a požadavky na interakci s uživateli (Stage 5). Přehled: Dvě paralelní větve: • výběr, zhodnocení a zdokumentování technického okolí systému; • detalní a strukturovaný popis procedur a uživatelských dialogů. Výstupy: • zvolené technického řešení (Selected Technical System Option); • popis technického okolí systému (Technical Environment Description); • logický návrh (Logical Design).



PHYSICAL DESIGN MODULE Fyzický návrh systému, SSADM Stage 6 Účel: • slouží jako spojovací článek mezi logickým návrhem a vlastní implementací systému. Přehled: Vstupy pro tento modul jsou z různých zdrojů: • Funkcionalita systému, datové popisy atd. jsou odvozeny z SSADM dokumentace. • Konkrétní metody implementace závisí na HW a SW. • Obecné zásady pro vývoj a systémovou dokumentaci jsou obvykle ovlivněny organizací uživatele systému. Výstupy: • fyzický návrh systému (Physical Design); • standardy pro vývoj aplikace (Application Development Standards); • fyzický popis prostředí (Physical Environment Specification). V dalším textu popíšeme nejdůležitější techniky a postupy, užívané metodologií SSADM.

4.2 Diagramy datových toků (DFD) V grafické formě popisují toky dat v systému a interakci s okolím. Specifikují zdroje a cíle dat, jejich transformace (hrubě) a identifikují místa, kde se data "skladují" (databáze). Slouží též k identifikaci hranice systému (zdroje či cíle dat mohou být vně systému).



Data Flow Model (DFM) je nejčastěji reprezentován formou diagramů datových toků - Data Flow Diagrams (DFD). DFM se používá v několika etapách SSADM, a to: • současný fyzický DFM (Current Physical Data Flow Model); • logický DFM (Logical Data Flow Model); • DFM požadovaného systému (Required System Data Flow Model). DFM se zkládá z: • DFD vrstvené do úrovní (Data Flow Diagrams); • popis elementárních procesů (Elementary Process Descriptions); • popis vnějších entit (External Entity Descriptions); • popis vstupů/výstupů (I/O Descriptions). Struktura SSADM - str. 17

Počítačem podporovaná výroba DFD se zkládá z následujících elementů: • Procesy, wkteré reprezentují transformaci nebo manipulaci s daty. • Datové toky, což jsou kanály mezi ostatními elementy,kterými mohou proudit předdefinované množiny dat. • Datové sklady, obsahující uložená data. Mohou být tzv. hlavní (main), které jsou persistentní, nebo přechodné (transient), ukládané dočasně. • Externí entity, což jsou zdroje nebo příjemci dat vně systému. Různé DFM modely se mohou od sebe mírně lišit ve formálním zápisu v závislosti na využití pro konkrétní účel. Používá se následující notace: • ovály jsou externí entity; • identifikátorem externí entity je malé písmeno; • obdélníky jsou procesy; • identifikátor procesu je číslo; • otevřené obdélníky jsou datové sklady; • identifikátor datového skladu má syntaxi 'D' plus číslo; • šipky jsou datové toky; • datové toky na spodní úrovni diagramu jsou popsány svým obsahem. Další doporučení: • v rámci jednoho diagramu duplikovaným datovým skladům nebo externím entitám se přidává pruh; • hvězdička v pravém dolním rohu obdélníka procesu značí hvězdička, že proces není dále dekomponován a bude pro něj existovat popis (Elementary Process Description);


Počítačem podporovaná výroba •

tečkovaný datový tok mezi externímy entitami značí důležitý datový tok mezi externími entitami za hranicemi systému.

Dekomponovatelné procesy jsou dále dekomponovány v dalších úrovních. • identifikátory procesů jsou vytvářeny z čísla dekomponovaného procesu a nového pořadového čísla, oddělených tečkou; • prostředky pro dočasné uložení dat jsou značeny 'T' plus číslo dekomponovaného procesu a nového pořadového čísla, oddělených '/'

4.2.1 SOUČASNÝ FYZICKÝ DFM (CURRENT PHYSICAL DATA FLOW MODEL) Současný fyzický DFM model je reprezentací datových toků a s nimi souvisejících procesů v současném systému. Obvykle se skládá z: • kontextový diagram (Context Diagram) - uvažuje celý systém jako jeden blok; • diagram toku dokumetů (Document Flow Diagrams) popisuje, jak v současném systému putují dokumenty a formuláře a jaký je jejich smysl; • diagram toků zdrojů (Resource Flow Diagrams) specifikuje toky "hmoty" spíše než informace. Nekonzistence mezi toky zdrojů a toky informace může znamenat problém v systému!



a Opera house manager Details of productions, artists and performances

Performance details

Opera booking system

Orders for tickets

b Customer

Tickets for operas

Satisfied order details

c Accounts

External entity

Document flow

External entity

4.2.2 DFM POŽADOVANÉHO SYSTÉMU (REQUIRED SYSTEM DATA FLOW MODEL) DFM požadovaného systému je založen na specifikaci funkce nového systému. Obvykle se skládá z kontextového diagramu, diagram toku dokumetů (Document Flow Diagrams) a diagram toků zdrojů (Resource Flow Diagrams).



DFD diagram požadovaného systému



DFD 2.úrovně pro proces 3



4.3 Specifikace požadavků (Requirements Definition / Specification) Účel RD technika nepoužívá diagramy. Pokrývá potřeby analýzy funkčních i nefunkcionálních požadavků. RD se používá od počátku projektu ke sběru a dokumentaci uživatelských požadavků na systém v tzv. katalogu požadavků (Requirements Catalogue). Zápis a použití Funkční požadavky (Functional Requirements) - zahrnují oblasti jako: • aktualizace; • dotazy; • reporty; • data; • rozhraní vůči jiným systémům. Funkční požadavky jsou v průběhu řešení projektu upřesňovány, neboť: • modelování ukáže na nutnost korekce požadavků, • některé požadavky mohou být v konfliktu, • jsou doplňovány další nefunkcionální požadavky, které mohou vyvolávat změny v jiných funkčních požadavcích. Nefunkcionální požadavky (Non-functional Requirements) Nefunkcionální požadavky popisují jak, v jaké kvalitě, na jaké úrovni apod. mají být určité požadavky splněny (řada nefunkcionálních požadavků popisuje množinu přípustných hodnost), viz obr. Některé důležité kategorie nefunkcionálních požadavků: • požadavky na úroveň služeb - definují vlastnosti systému z hlediska dostupnosti služeb v čase, doby odezvy, propustnosti systému (počet transakcí za časovou jednotku), spolehlivost systému Struktura SSADM - str. 23

Počítačem podporovaná výroba • omezení přístupu (access restrictions) specifikuje oprávnění

jednotlivých uživatelů v rámci systému • zabezpečení systému proti neočekávaným selháním mechanismus a perioda zálohování, zotavení z chyb • monitorování a logování může být požadováno pro účely dokumentace užívání a běhu systému • omezení při návrhu systému - téměř vždy se vyskytují a zahrnují požadavky na konverzi dat (může být i funkční požadavek na import/export dat), omezení daná rozhraními vůči jiným systémům, ergonomická omezení uživatelského rozhraní apod.



Parciální rozklad struktury dokumentů


Počítačem podporovaná výroba Katalog požadavků List z katalogu požadavků a příklad vyplnění pro úlohu analýzy systému rezervace vstupenek. User-defined priority of the requirement (L=low, M=medium, H=high)

This is where the requirement comes from

Source

Priority

User responsible for negotiating the requirement

Owner

Functional requirement(s)

A definition of non-functional aspects

Target value

Textual description of the non-functional requirement

Benefits

Requirement ID A description of the requirement

Non-functional requirement

Description

Unique identifier

This is what should be achieved

Acceptable range

Acceptable range

Comments Any relevant comment that can influence the solution

Benefits to the user as a result of meeting this requirement

Comments/suggested solutions Suggested solution from the user, if any

Related documents

Any document that may be of relevance

Related requirements

A number of requirements may influence the solution

Resolution

If this requirement is mentioned in another SSADM document, it should be written here


Počítačem podporovaná výroba Příklad vyplněného listu z Katalogu požadavaků

Source

Priority

Box office manager

Owner M

Requirement ID 3

Functional requirement(s) The new system should provide the box office staff with a method of batching the tickets required for printing so they do not require printing at the time the order is satisfied.

Non-functional requirement Target value

Description Frequency of printing of tickets.

Acceptable range

Twice per day

Comments Must catch the daily post

Once per day

Benefits At present, all tickets must be printed at the time the order is satisfied. This means that tickets must stand around awaiting envelopes. This causes tickets to be lost. Batching the production of tickets would help to solve this problem.

Comments/suggested solutions

Related documents Assembly report onto the efficiency of the opera house.

Related requirements

Resolution



4.4 Funkční specifikace (Functional Specification / Definition) Funkční specifikace je jádrem analýzy a návrhu celého systému. V rámci této specifikace budeme funkcemi rozumět jednotky, které jsou z hlediska uživatele rozeznatelné jako mechanismy fungování systému. Jednotlivé funkce se identifikují na základě Katalogu funkcí (Requirements Catalogue), DFD modelu požadovaného systému (Required System Data Flow Model) a E/E modelu (Entity/Event Model). Dokumentace ke každé funkci se nazývá Definice funkce (Function Definition). Související podpůrnou dokumentací je popis I/O struktur.

Universal Function Model

Function output process

Event output and enquiry output Input

Function input processes

Event(s) and enquiry triggers

Update or enquiry process

Integrity errors

Function error process Syntax errors Control errors

Valid output

Error output

Database input/output

Database


Počítačem podporovaná výroba Veškeré funkce se skládají ze standardizovaných komponent, které tvoří Obecný funkční model (Universal Function Model), poskytující charakteristiku funkce pomocí procesů a datových toků. UFM procesy: • proces vstupu • proces aktualizace/dotaz • proces výstupu • proces zpracování chyb UFM datové toky: • vstup (zvenčí) • chyby syntaxe/řízení • události/dotazy • vstup/výstup databáze • výstup aktualizace/dotazu • chyby integrity • platný výstup • chybový výstup Veškeré funkce jsou kategorizovány takto: • dotazy nebo aktualizace; • off-line nebo on-line; • vyvolány uživatelem nebo systémem. Typ funkce je dán kombinací možností z těchto kategorií a určuje tak následné aktivity při návrhu systému.

4.4.1 ODVOZOVÁNÍ FUNKCÍ Funkce jsou odvozovány z řady zdrojů, obvykle takto: • aktualizační funkce (a některé hlavní dotazovací funkce) z DFD modelu požadovaného systému. • dotazovací funkce z Katalogu požadavků. Struktura SSADM - str. 29

Počítačem podporovaná výroba Paralelně s identifikací aktualizačních funkcí se definují Události (Events), které slouží jako spouštěče (triggers) aktualizací. Recipročně, následné Entity-Event modelování může nalézt nové události, které si vyžádají ošetření dalšími funkcemi. • Odvozování funkcí z DFD modelu požadovaného systému Uživatelem vyvolané funkce (User-initiated functions) se identifikují procházením DFD od vstupního datového toku přes procesy, které data zpracovávají, až k výstupu (opět datový tok nebo datový sklad). Systémem vyvolané funkce (system-initiated functions) se detekují v DFD z procesů, které nemají vstup z externí entity (např. Proces 3.3 - Print tickets). • Odvozování funkcí z Katalogu požadavků Z Katalogu funkcí vyplývá řada uživatelských požadavků na tiskové sestavy, dotazy atd., které je třeba zkonvertovat do definic funkcí. • Odvozování funkcí z jiných zdrojů Některé z funkcí, popsaných DFD, může být potřeba na základě dalších informací rozdělit na dvě, např. existuje-li požadavek na dostupnost těchto funkcí on-line i off-line. • Konzultace s uživatelem Veškeré definované funkce je nezbytné konzultovat s uživatelem.



4.4.2 I/O STRUKTURY (I/O STRUCTURES) I/O struktury popisují vstupy/výstupy funkcí a jsou součástí podpůrné dokumentace funkcí. Datové položky jsou strukturované do diagramů. Tyto diagramy se využívají jako základ pro návrh dialogů v modulu Logical System Specification Module. Pro každou funkci se identifikuje jedna I/O struktura, a to obvykle z popisu vstupů/výstupů funkce (I/O Descriptions). Příklad tabulky I/O Descriptions relevantní funkci ‘receive orders for tickets’ z úlohy rezervace vstupenek: From

To

Data flow name

c

3.1

Order for tickets

Data content

Comment

Customer name Customer address Date of performance Theatre area No. of seats required Price per seat Total price for each seat Total for the Whole order

A number of tickets can be on one order

Method of payment Credit card no. Expiration date 3.1

b

Invalid orders

Customer name Customer address Date of performance Theatre area No. of seats required Price per seat Total price for each seat Total for the Whole order

The original order is sent back with a note detailing the errors

Method of payment Credit card no. Expiration date 3.2

d

Satisfied orders

Customer name Customer address Date of performance Theatre area No. of seats satisfied

3.2

b

Unsatisfied orders

For each of the order lines satisfied

Customer name Customer address


Počítačem podporovaná výroba Každá I/O struktura je dokumentována popisem (I/O Structure Description) ve formě tabulky I/O Structure name:

4-1

Ticket orders

Data flows represented:

c-3.1 3.1-b

I/O Structure Element Data item Customer name

Customer name

Customer address

Customer address

Production details

Date of performance Theatre area

Seat details

No. of seats Price per seat Total

No. of seats required

No. of seats

Header details

Customer name Customer address

Reason for rejection

Reason for rejection

Comments

This will be an internally generated message

a diagramem


Počítačem podporovaná výroba Dokumentace funkcí a názvosloví Každá funkce je dokumentována ve formuláři Function Definition Form. Zkládá se z následujících (M = povinných (mandatory) a O = volitelných (optional)) položek: • Název funkce: Function name (M) Smysluplný název funkce. • Identifikár fce: Function ID (M) Unikátní identifikátor • Typ: Type (M) Typ funkce (update/query, on-line/off-line, user/system initiated) • Uživatelská role: User roles (M pro uživatelem vyvolané fce) Role uživatele v systému. • Popis fce: Function description (M) Stručný popis fce a okolností, za kterých je vyvolána. • Zpracování chyb: Error handling (O) Stručný popis reakce na chyby. • DFD procesy: DFD processes (M pro aktualizační fce) ID DFD procesu nejnižší úrovně, vztahujícího se k dané fci. • Události: Events (M pro aktualizační fce) Pro každou aktualizační fci musí být událost, která ji spouští. Je-li takových více, musí být specifikován jejich vzájemný vztah (komplementární, vzájemně se vylučující). • Frekvence vzniku událostí: Event frequency (M pro aktualizační fce) Kolikrát událost nastane během jednoho vyvolání fce. • I/O popis: I/O Descriptions (M pro aktualizační fce) reference. • I/O struktury: I/O Structures (M) - reference. • Katalog požadavků: Requirements Catalogue Ref (M pro dotazovací fce) - reference na všechny související požadavky. • Objemy: Volumes (M) Frekvence používání fce (pro účely optimalizace). • Související fce: Related functions (O) - refence. • Dotazy: Enquiries (M pro fce obsahující dotaz) - reference.


Počítačem podporovaná výroba • Frekvence dotazů: Enquiry frequency (M pro fce obsahující

dotaz) Kolikrát je dotaz položen během jednoho vyvolání fce. • Společné zpracování: Common processing (O) Reference na základní popis součástí sdílených více funkcemi. • Název dialogu: Dialogue names (M pro uživatelem vyvolané fce) Reference na relevantní dialogy. • Požadavky úrovně služeb: Service level requirements (M) Popis nefunkcionálních požadavků. Function name

Receive orders for tickets

Type

Update/on-li/user-initiated

User roles

Booking clerk

Function ID

4

Function description This function is invoked to enable the booking clerk to input the details of an order for tickets received from a customer. The system validates the whole order and if necessary rejects it, returning it directly to the customer. After validation of the order where possible seats are allocated to the order to satisfy it. If the order lines are satisfied then the tickets will be printed (later). If not the customer is informed. All the details of the order are entered into the database. Error handling

3.1 Receive and validate orders; 3.2 Satisfy orders

DFD processes Events 3.1.1 Order receipt I/O Descriptions

Event frequency

1

Enquiry frequency

N/A

c-3.1 3.1-b 3.2-d 3.2-b

I/O Structures 4-1 Ticket orders Requirements Catalogue Ref Volumes

Average 100 per day; maximum 300 per day

Related functions Enquiries

5

Print tickets

None

Common processing

None

Dialogue names

Receive order for tickets

Service level requirements Description

Target value

Range

Comments



4.5 Popis života entit (Entity Life Histories) Účel Určuje (zpravidla ve formě incidenční tabulky), které události (přicházející zvenčí systému nebo významné časové okamžiky) ovlivňují které entity či jejich datové reprezentace. Zpravidla se uvádějí i požadavky na priority zpracování při souběhu více událostí. Analýza životního cyklu entit (ELH) se uskutečňuje technikou zvanou entity/event modelling. Smyslem je nalézt příčiny změn v datech v systému, definovat jejich omezení a modelovat přesný vliv na jednotlivé datové elementy. ELH analýza je technika založená na stromových diagramech a zachycuje životní cyklus entity od jejího vzniku až po zánik, reflektuje veškeré události, které mohou entitu pozměnit, a zachycuje jejich časový sled.

4.5.1 MATICE UDÁLOST/ENTITA (EVENT/ENTITY MATRIX) E/E matice je výchozím bodem pro ELH analýzu. Poskytuje křížový pohled na entity z logického datového modelu požadovaného systému a události, zdokumentované ve Funkční specifikaci.


Počítačem podporovaná výroba Příklad matice událost/entita Entity

Artist

Order

Order line

Arrival of order

C

C

Details sent to credit company

M

Credit card approved

M

Request for new details sent

M

New details received

M

M

Tickets sent

M

D/M

Performance takes place

M

Change to personal details

M

Retention period expires

D

Event

Receive new production details

Artist in performance

Bookable seat

Opera performance

C

C

Performance details finalised

M/D

M

C

C

Opera house details changed

M

M

M

M

Part of theatre

Production

Seat at performance M

D

M

C C C/M

M

M

Každý element v E/E matici může být: • prázdný - entita není událostí ovlivněna • M - entita je událostí modifikována

• C - entita je událostí vytvořena • D - entita je událostí zrušena

Matice se užívá ke kontrole, že: • všechny entity vznikají alespoň jednou událostí,

• každá událost ovlivňuje alespoň jednu entitu.



4.5.2 ELH DIAGRAM (ENTITY LIFE HISTORY DIAGRAM) Výchozím materiálem pro tvorbu je E/E matice. Pro každou entitu se vytváří vlastní diagram, obsahující stromovou strukturu, kde kořenem je zvolená entita, listy reprezentují efekt identifikovaných událostí a mezilehlé uzly definují strukturu. Posloupnost (sequence) v životním cyklu je v diagramu rozlišena horizontální úrovní (např. 'start of order' předchází 'tickets sent' atd.). Kvalifikátory (Effect Qualifiers) rozlišují účinek události v závislosti na okolnostech - např. diferencují událost 'arrival of order' podle toho, zda přichází od předplatitele či nikoliv -zapisují se do kulatých závorek. Pokud je třeba rozlišit efekt události v různých rolích, zapisují se role do hranatých závorek. Výběr (Selection) mezi možnostmi (viz 'arrival of order') je označen kroužkem (alespoň a nejvýše jedna alternativa). Opakování (Iteration) je označeno hvězdičkou a znamená libovolný (i nulový) počet opakování, která se nepřekrývají (např. 'Change personal details') Paralelní struktura (Parallel Structure) je označena dvojitou čarou - viz 'Performance takes place' a 'Change of personal data'. Tento zápis neznamená ani alternativu, ani že událost má vliv na entitu ve stejném okamžiku, ale pouze to, že pořadí není ničím určeno. Značky ukončit & pokračovat (Quit & Resume) umožňují 'skoky' v diagramu, tj. po události Qn pokračovat na odpovídajícím Rn.



Entity Life History diagram entity 'Order' Struktura SSADM - str. 38


4.6 Identifikace a návrh dialogů (Dialogue Identification And Design) Úvod Návrh dialogů definuje uživatelské rozhraní funkcí nového systému. Zatímco E/E model sleduje interakci procesů s daty, návrh dialogů sleduje interakci procesů s uživatelem. Specifikace a logický návrh se uskutečňují po krocích dvěma technikami: • identifikace dialogů (Dialogue identification), která analyzuje požadavky na interakci a • návrh dialogů (Dialogue design), ve kterém se obsah a struktura dialogů definují detailně. Identifikace je založena na tzv. uživatelských rolích v systému. Každá role má určitá oprávnění a vyžaduje přístup k určitým funkcím právě prostřednictvím dialogů. Návrh dialogů vychází z vstupů a výstupů funkcí, popsaných v I/O strukturách Funkční specifikace. Názvosloví • Katalog uživatelů: User Catalogue obsahuje seznam on-line uživatelů systému. • Uživatelské role: User Roles vycházejí ze seznamu uživatelů a zahrnují veškeré kategorie uživatelů systému. • Matice role/funkce: User Role/Function Matrix představuje křížové odkazy mezi rolemi a funkcemi systému. Určuje jednotlivé Dialogy (Dialogs). • Struktura dialogů: Dialogue Structure popisuje jednotlivé elementy dialogu, z nichž každý se váže k datovým položkám. Každý element dialogu (Dialog Element) je dokumentován. • Logické sdružování dialogových elementů: Logical Grouping of Dialogue Elements (LGDEs) je popsáno kolekcemi dialogových elementů. Odlišné varianty cesty dialogem jsou popsány pomocí LGDEs v tabulce (Dialogue Control Table). Struktura SSADM - str. 39

Počítačem podporovaná výroba • Menu struktury: Menu Structures popisují hierarchii dialogů,

zatímco Příkazové struktury Command Structures definují posloupnost v předávání řízení při ukončení dialogu. Zápis a užití Identifikace dialogů (Dialogue identification) je výsledkem řady úkonů, a to: • tvorby katalogu uživatelů (User Catalogue); • identifikace uživatelských rolí (User Roles); • identifikace požadovaných dialogů; • identifikace kritických dialogů. Výstupem jsou příslušné odpovídající tabulky. Tvorba katalogu uživatelů Katalog uživatelů popisuje uživatele systému a jejich úlohu v systému. Job title

Job activities description

House day manager

Organise the performance details Set up and fix artist involvement

Opera house manager

Input and fix production details Organise the performance details Set up and fix artist involvement

Booking office clerk

Receive and action personal booking applications Receive and action telephone booking applications

Postal office clerk

Receive and action booking applications coming per mail

User Catalogue for Opera Booking System

Identifikace uživatelských rolí Každá uživatelská role vymezuje působnost a odpovědnost v rámci systému a disponuje určitými prámy v systému. Každá role představuje jednoho nebo více uživatelů a každému uživateli je přiřazena jedna (nebo více) rolí. Struktura SSADM - str. 40

Počítačem podporovaná výroba Role se identikují na základě katalogu uživatelů, přičemž se přihlíží k externím entitám DFD. Smyslem je sdružit uživatele systému do přesně definovaných skupin. User role

Job title

Activities

House manager

House day manager Opera house manager

Organise the performance details Set up and fix artist involvement Input and fix production details

Booking clerk

Booking office clerk

Receive and action personal applications Receive and action telephone applications Receive and action postal applications Dispatch tickets to customers Answer telephone enquiries on perfomances Answer telephone enquiries on applications

Postal office clerk Information clerk

Information clerk

User Roles for the Opera Booking System

Pozornost je nutné věnovat nejen identifikaci funkcí, užívaných jednotlivými skupinami uživatelů, ale i frekvenci a charakteru užití těchto funkcí. Identifikace požadovaných dialogů Dialogy jsou identifikovány již ve funkční specifikaci a to v tom smyslu, že každá funkce s on-line uživatelskou interakcí vyžaduje dialog. Identifikace je podporována maticí role/funkce (User Role/Function Matrix): Function User role

Receive orders for tickets

House manager

X

1

Booking clerk

X

2

Information clerk

Print performance advance details

Maintain production details

Maintain performance details

1

X

X

X

X

1

Maintain Display theatre application details details

X

Display production/ performance details

Produce application statistics

X

1

X

2

X

1

X

1

X

1

X

1

X

1

X

1

User Role/Function Matrix for Opera Booking System


Počítačem podporovaná výroba Obvykle pro každou funkci postačuje jeden dialog. Je-li nutné rozlišovat pohledy na data v závislosti na roli, číslují se dialogy pomocným indexem. Identifikace kritických dialogů Nejdůležitější dialogy se nazývají 'kritické'. Určujícími faktory jsou: • velká frekvence použití; • složitost přístupu k datům a manipulace s nimi; • důležitost pro systém; • 'novinky'. Receive orders for tickets

Print performance advance details

Maintain production details

Maintain performance details

House manager

X

X

X

C

Booking clerk

C

Function User role

Information clerk

X

Maintain Display theatre application details details

X

Display production/ performance details

Produce application statistics

X

X

X

X

C

X

C

C

User Role/Function Matrix for Opera Booking System showing critical dialogues

Návrh dialogů Návrh vychází z I/O struktur identifikovaných v rámci funkční specifikace a matice role/funkce. Jednotlivými kroky jsou: • tvorba dialogových struktur (Dialogue Structures); • identifikace sdružování do LGDEs; • identifikace navigace v dialozích; • návrh struktur menu (Menu Structures) a příkazových struktur (Command Structures); • definice nápovědy k dialogu (Dialogue Help). Při tvorbě dialogových struktur vyjdeme z diagramu, vytvořeného na základě I/O struktur - viz obr. Listy stromu reprezentují skupiny vstupních/výstupních datových položek, tvořících dialogové elementy.



Výchozí dialogová struktura pro 'receive orders for tickets'



4.7 Výhody použití SSADM The following is a list of benefits gained from using SSADM3. The approach SSADM takes to make these benefits achievable are also described. 1. Deliver the system to users on time Timeliness depends on two things : • good planning; and • good management and control. SSADM has a modular structure which relates directly to project deliverables and helps in all aspects of project management. It gives a clear specification of what is to be produced and how it is to be managed and reviewed. There are well defined interfaces to management and specialist techniques. 2. Deliver systems that meets user's needs By continuously involving users, by modelling business activities and work practice, by using prototyping, by making the IT professional's thinking visible through diagrammatic techniques, SSADM enhances the prospects for success on large and small projects. 3. Deliver systems which respond to changes in the business environment SSADM helps in several ways here. Business Activity Modelling and Work Practice Modelling ensure that the focus of the project is on what the business requires. The system documentation produced makes visible : • business objectives; • practitioners’ thinking and understanding of the business objectives; 3

AN INTRODUCTION TO STRUCTURED SYSTEMS ANALYSIS & DESIGN METHODOLOGY (SSADM) . Office of the Government Chief Information Officer, The Government of the Hong Kong Special Administrative Region, June 2005


Počítačem podporovaná výroba • the link between the needs of the business and the system under development; and • a precise specification for the design, building, maintenance and enhancement of applications. SSADM precisely describes what has been captured in an advanced application development environments include 3GL, 4GL, Client Server, distributed systems, and many more. 4. Improve the effective and economic use of the skill available SSADM uses the most commonly available skill in a wide market place – for example, Data Flow Modelling, Logical Data Modelling and Jackson-like structure diagramming. It promotes their effective use by aiding forward planning, and building up the skills base in the organization and on particular projects. 5. Improve quality by reducing error rates Quality can be improved by detecting errors early in the lifecycle, especially by involving users as well as skilled practitioners in checking for errors. Rigorous techniques promote accuracy, with adequate checks of completeness and consistency. By defining the required quality of design documents, and stating the tests for them, SSADM promotes better quality management. 6. Improve flexibility Every application development is different. The ability of tailoring SSADM to suit different projects is a major factor for organizations who wish to reuse their resource skills on other projects, and to be able to benefit from the many different ways in which SSADM techniques and products may be applied. 7. Improve productivity Major boosts to productivity performance are achieved by : • providing well documented techniques which accurately specify business and system requirements; Struktura SSADM - str. 45

Počítačem podporovaná výroba • defining what is needed in automated support tools in support for SSADM's techniques; • using a product-oriented approach, avoiding the need to undertake unnecessary tasks, or to produce documentation at unnecessary levels of details; • using techniques to make thinking visible at each step; and • promoting the specification of quality criteria. 8. Avoid lock-in to a single source of supply The separation of logical system specification and physical design helps to establish a new layer of portability. It reduces the cost of re-implementing the system on new hardware and/or software. 9. Avoid IT developers’ bureaucracy SSADM has been designed to provide useful tools for project managers and to transfer expertise to practitioners. Its use makes benefits, as well as costs, visible to both business and IT management and users.

4.8 Doporučená literatura: • Philip L. Weaver, ‘Practical SSADM: version 4’, AddisonWesley, 1998 • C. Ashworth and M. Goodland, ‘SSADM. A Practical Approach’, McGraw-Hill, 1992


Téma 2: Nástroje pro analýzu systému a návrh SW produktu

Recommend Documents