Wyniki wyszukiwania - BazTech

1

Application of use cases and the UML language in the design of intelligent transportation systems

Kamiński Tomasz, Kamiński Piotr

Journal of civil engineering and transport

|

2023

|

Vol. 5, No. 2

39--48

EN

The purpose of this paper is to analyse the applicability of the description of use cases and the UML language that takes them into account in the process of designing Intelligent Transportation Systems (ITS). These systems are built using standardized solutions and devices, but the system itself and the individual organizational solutions used therein are individually tailored to the needs of the employer - the manager of the road network on which the system is implemented. The first stage of the project may include verbal descriptions of the requirements, proposals for solutions, relations between system elements, contents of databases, etc. However, the next stages of the work should involve the use of tools to formalize the record so that it is understandable to the entire project team, the contractors of the system elements, and then form the basis for the development of design and detailed documentation. The tools that can be used in the design process of an ITS solution are, described in the paper use cases that define the interaction of system users (“actors”) with the system, and the UML language used in the design of information systems. The paper describes the legal basis for ITS solutions, ways of defining use cases, the UML, including use case diagrams, behavioural diagrams and structural diagrams. Examples of the application of the UML to describe the design of an ITS system are also presented.

PL

Celem artykułu jest analiza możliwości zastosowania opisu „przypadków użycia” i uwzględniającego je języka UML w procesie projektowania Inteligentnych Systemów Transportowych (ITS). Systemy te budowane są z użyciem znormalizowanych i ustandaryzowanych rozwiązań i urządzeń, jednak sam system i poszczególne rozwiązania organizacyjne w nim zastosowane są indywidualnie dostosowywane do potrzeb zamawiającego – zarządcy sieci dróg na których został zaimplementowany system. Pierwszy etap projektu może zawierać słowne opisy wymagań, propozycje rozwiązań, relacji między elementami systemu, zawartości baz danych itp. Jednak kolejne etapy prac powinny polegać na użyciu narzędzi umożliwiających sformalizowanie zapisu, tak aby był on zrozumiały dla całego zespołu projektowego, wykonawców elementów systemu, a następnie stanowił podstawę do opracowania dokumentacji projektowej i wykonawczej. Narzędziami, które mogą być zastosowane w procesie projektowania rozwiązania ITS są, opisane w artykule, „przypadki użycia” definiujące interakcję użytkowników systemu („aktorów”) z systemem oraz stosowany w projektowaniu systemów informatycznych język UML. W artykule opisano podstawy prawne funkcjonowania rozwiązań ITS, sposób definiowania „przypadków użycia”, język UML, w tym diagramy przypadków użycia, diagramy behawioralne i diagramy strukturalne. Przedstawiono również przykłady zastosowania języka UML do opisu projektu systemu ITS.

2

Weryfikacja aktywności systemów modelowanych na bazie architektury SOA - prowadzona w oparciu o wymagania zadane diagramami przypadków użycia

Klimek R., Skrzyński P., Turek M.

Automatyka / Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie

|

2010

|

T. 14, z. 3/2

893-903

PL

Artykuł porusza zagadnienia formalnej weryfikacji wymagań dla tzw. systemów biznesowych, wyrażonych przez model przypadków użycia oraz scenariuszy przypadków użycia UML. Zaproponowana została metodologia opisująca przejście od diagramów przypadków użycia do diagramów aktywności. Do specyfikacji żądanych własności systemu została wykorzystana logika temporalna. Własności tak zakodowane mogą być następnie poddawane procesom weryfikacji z wykorzystaniem wnioskowania dedukcyjnego metodą tablic semantycznych. Zaproponowane zostały metody pozyskiwania formuł logiki temporalnej bezpośrednio ze scenariuszy przypadków użycia zapisanych w diagramach czynności UML.

EN

The article discusses the issue of f formal requirements verification for so-called "business systems" - expressed through an UML Use-Case model and Use-Case scenarios. A methodology for transformation of UML Use-Case diagrams to Activity diagrams has been described. To specify advanced system requirements a temporal logic notation was used. These requirements (encoded in such way) could be verified with a deductive inference based on semantic tables. The methods for obtaining temporal logic formulas directly from Use-Case scenarios stored in the UML Activity diagrams have also been introduced.

3

Proces asynchronicznych przeglądów specyfikacji wymagań

Michalik B., Mazur M., Olek Ł.

Prace Naukowe Instytutu Informatyki Stosowanej Politechniki Wrocławskiej. Konferencje

|

2007

53-62

PL

Wiele specyfikacji wymagań (SRS) zwiera niepoprawnie spisane wymaganie. Jakość produktu wynika z jakości każdego z komponentów. Posiadając złe wymagania nie jesteśmy w stanie stworzyć wysokiej jakości produkt. W celu zwiększenia jakości specyfikacji wymagań, stosujemy przeglądy, ponieważ jesteśmy opłacani za to co tworzymy. Obie strony muszą jednakowo rozumieć spisane wymagania. Kolejnym aspektem jest koszt takiego przeglądu. Znaczenie tego kryterium jest jeszcze większe, w przypadku gdy zespół pracuje zdalnie. Rozwiązaniem tych problemów jest propozycja asynchronicznych przeglądów. Proces ten składa się z czterech faz: przygotowanie, przegląd, oczyszczanie oraz analiza ryzyka. Faza przeglądu jest oparta na metodzie przeglądów n-częściowych. W celu oszacowania liczby defektów pozostających w specyfikacji stosuje się metodę podwójnego łowienia. Jeśli ta liczba jest akceptowalna, proces przechodzi do następnej fazy. W ostatnim rozdziale opisano prototyp rozwiązania - aplikację która wspiera proces asynchronicznych przeglądów.

EN

Many software requirements specifications (SRS) are filled with badly written requirements. Quality of the products base on quality of all components, with bad requirements we are not able to write good software. To increase SRS quality requirements reviews can be used. We are also expected to write what our customers paid for. We must assure that both sides understand requirements specification the same way. Another aspect is cost of requirements review meeting. This is essential when team members works remotely on the project. To address these problems asynchronous requirements review process was proposed. This process consist of four phases: preparation, review, data cleaning and risk analysis. Review phase is build on N-fold reviews method. Capture-recapture method was used to estimate number of defect left in specification after review. If this number is acceptable we can move to the next phase of project. In the last chapter prototype of software that can support asynchronous reviews process was described.