Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski
|
|
- Elżbieta Rosińska
- 8 lat temu
- Przeglądów:
Transkrypt
1 INŻYNIERIA OPROGRAMOWANIA wykład 6A: ANALIZA i PROJEKTOWANIE wg RUP dr inż. Leszek Grocholski ( na podstawie książek o RUP ) Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski
2 OBIEKTOWE wg RUP PLAN PREZENTACJI 3. Analiza versus projektowanie wg RUP 4. Jak szczegółowy powinien być projekt? 5. Pracownicy i artefakty 6. Model projektowy 7. Model analityczny 8. Rola interfejsów 9. Artefakty systemów czasu rzeczywistego 10. Projektowanie oparte na komponentach 11. Przepływ pracy ( workflow) 12. Narzędzia wspomagające 13. Podsumowanie Leszek Grocholski II Uni. Wroc. 2
3 CELEM PRZEPŁYWU PRACY ANALIZA i PROJEKTOWANE wg RUP jest przetłumaczenie wymagań na dokumentacje, która opisuje jak zaimplementować system. Ażeby dokonać tego tłumaczenia, trzeba zrozumieć wymagania i przetransformować je do postaci projektu systemu. Co więcej, należy przy tej okazji zaproponować najlepszą strategię implementacji systemu. Wcześniej w przedsięwzięciu należy podjąć decyzje co do zdrowych podstaw systemu w postaci jego architektury. Leszek Grocholski II Uni. Wroc. 3
4 ANALIZA i PROJEKTOWANIE podstawy Korzystając z architektury można zaprojektować system, który jest łatwy do zrozumienia, zbudowania i ewoluowania. Potem trzeba tak dopasować projekt, aby pasował on do środowiska implementacyjnego. Następnie należy zaprojektować środowisko implementacyjne zapewniające: efektywne przetwarzanie, stabilność, skalowalność, testowalność i spełnienie innych wymagań jakościowych. Leszek Grocholski II Uni. Wroc. 4
5 Analiza versus projektowanie ( Analysis versus Design ) Celem analizy jest przetransformowanie wymagań na system do formy, która dobrze pasuje do przestrzeni pojęć projektanta oprogramowania tzn. zbioru klas i podsystemów. Transformacja ta jest sterowana przypadkami użycia i dodatkowo niefunkcjonalnymi wymaganiami na system. Analiza skupia się na zapewnieniu tego, że system spełniał wymagania funkcjonalne. W uproszczeniu analiza ignoruje większość wymagań niefunkcjonalnych na system i również ograniczenia narzucane przez środowisko implementacyjne. W wyniku tych założeń analiza określa bliski ideałowi obraz systemu. Leszek Grocholski II Uni. Wroc. 5
6 Analiza versus projektowanie ( Analysis versus Design ) cd. Celem projektowania jest, z drugiej strony zaadoptowanie wyników analizy do ograniczeń narzuconych przez wymagania niefunkcjonalne, środowisko implementacyjne, wymagania wydajnościowych itd. Projektowanie przefiltrowywuje rezultaty analizy. Skupia się na optymalizowaniu projektu systemu przy zapewnieniu spełnienia przez niego wymagań. Leszek Grocholski II Uni. Wroc. 6
7 Jak daleko musi pójść projektowanie? ( How Far Must Design Go?) Projektowanie musi zdefiniować system na takim poziomie, aby możliwa była jego jednoznaczna implementacja. To oczywiste sformułowanie ma różne znaczenie, w zależności od przedsięwzięcia i organizacji. W niektórych przypadkach, projekt musi być dopracowany do poziomu na którym możliwa jest systematyczna transformacja od projektu do kodu. Leszek Grocholski II Uni. Wroc. 7
8 Pracownicy i Artefakty (Workers and Artifacts ) RUP wyraża analizę i projekt w terminologii pracowników, artefaktów i przepływu pracy. Pokazuje, jakie artefakty produkowane są przez których pracowników oraz zakresy odpowiedzialności pracowników. Architekt prowadzi i koordynuje techniczne czynności i artefakty w przedsięwzięciu. Ustanawia ogólną strukturę i wygląd dla każdej perspektywy architektonicznej: dekompozycji widoków, grupowania elementów i interfejsów między głównymi grupami. W kontraście ze spojrzeniami innych pracowników, spojrzenie jest raczej jednym płytkim oddechem a nie głębokim łyknięciem powietrza. Leszek Grocholski II Uni. Wroc. 8
9 Leszek Grocholski II Uni. Wroc. 9
10 PRACOWNICY cd.. Projektant Projektant definiuje: odpowiedzialności, operacje, atrybuty powiązania jednej lub wielu klas i determinuje jak one powinny zostać dostosowane do środowiska implementacyjnego. W dodatku projektant może być odpowiedzialny za jeden lub więcej pakietów projektowych i projektowych podsystemów, włączając w to klasy wchodzące w skład pakietów czy podsystemów. Inni Leszek Grocholski II Uni. Wroc. 10
11 PRACOWNICY cd.. Projektant bazy danych jest potrzebny kiedy projektowany system zawiera bazę danych. Projektant Kapsuł ( Capsule Designer ) dla systemów czasu rzeczywistego Odmiana projektanta, który koncentruje się na zapewnieniu, że system jest zdolny odpowiadać na zdarzenia zgodnie z wymaganiami czasowymi, poprzez odpowiednie użycie bieżących technik projektowych. Kontroler Architektury i Projektu ( Architecture Reviewer i Design Reviewer ) przegląda architekturę i projekt. Leszek Grocholski II Uni. Wroc. 11
12 KLUCZOWE DLA ANALIZY I PROJEKTOWANIA ARTEFAKTY: Model Projektowy ( Design Model ), który jest najważniejszym dokumentem dla wytwarzanego systemu. Dokument Architektury Systemu ( Software Architecture Dokument SAD), którego zadaniem jest uchwycenie wielu spojrzeń architektonicznych na system. Leszek Grocholski II Uni. Wroc. 12
13 MODEL PROJEKTOWY (THE DESIGN MODEL ) Składa się on ze zbioru elementów diagramów współpracy ( collaboration diagrams ) oddających sposób zachowania systemu. Zachowania z kolei są pochodną informacji uzyskanych z modelu PU i wymagań niefunkcjonalnych. Model projektowy składa się diagramów współpracy klas, które mogą być agregowane w pakiety i podsystemy w celu pomocy w zorganizowaniu modelu i dostarczenia modułów składowych bloków modelu. Leszek Grocholski II Uni. Wroc. 13
14 MODEL ANALIZY ( ANALITYCZNY ) ( THE ANALYSIS MODEL) W niektórych firmach w tych gdzie systemy żyją wiele dekad lub gdzie istnieje wiele wariantów systemu osobny model analityczny jest uważany za użyteczny. Taki model analityczny jest abstrakcją czy generalizacją projektowego. Model taki nie zawiera większości szczegółów opisujących sposób działania systemu a dostarcza jedynie przeglądu funkcjonalności systemu. Dodatkowa praca potrzebna do zachowania jednoznaczności modeli analitycznego i projektowego musi być równoważona korzyściami z posiadania widoku systemu reprezentującego jedynie najbardziej ważne szczegóły sposoby działania systemu. Leszek Grocholski II Uni. Wroc. 14
15 ROLE INTEREJSÓW ( THE ROLE OF INTERFACES ) Interfejsy są używane systemów celu wyspecyfikowania zachowań oferowanych przez klasy, podsystemy systemów komponenty, w niezależny od implementacji tych zachowań. Specyfikują one za zbiór operacji wykonywanych przez elementy modelu system. Obejmują również ilość rodzaj parametrów zwracanych przez podsystemy. Każde 2 elementy systemu posiadające te same interfejsy są zamienialne. Interfejsy poprawiają elastyczność projektu dzięki ograniczenia zależności pomiędzy częściami systemu. Czynią go łatwiejszym do wprowadzania zmian. Leszek Grocholski II Uni. Wroc. 15
16 ARTEFAKTY SYSTEMÓW CZASU RZECZYWISTEGO ( ARTEFACTS FOR REAL TIME SYSTEMS ) Systemy czasu rzeczywistego to systemy, które charakteryzują się szczególnymi wymaganiami czasowymi: krytycznymi czasami reakcji, często z dużymi wymaganiami dot. rozmiarów przetwarzanych danych. Wiele z tych ograniczeń jest krytyczne. Leszek Grocholski II Uni. Wroc. 16
17 RUP opisuje następujące krytyczne artefakty: Kapsuła : specjalny wzorzec projektowy, reprezentujący wykapsułkowany wzorzec sterowania w systemie. Kapsuły maja porty, przez które komunikują się z innymi kapsułami. Protokół: specyfikuje sposób w jaki zbiór portów się komunikuje wymianę komunikatów i ich uporządkowanie w czasie i przestrzeni. Zdarzenie: jest specyfikacją wystąpienia czegoś w czasie i przestrzeni lub mniej formalnie wystąpienie czegoś na coś system musi zareagować. Sygnał: jest asynchronicznym zdarzeniem które może spowodować przejście pomiędzy stanami maszyny stanowej pewnego obiektu. Leszek Grocholski II Uni. Wroc. 17
18 PROJEKTOWANIE BAZUJĄCE NA KOMPONENTACH ( COMPONENT BASED DESIGN) Komponenty są elementami modelu implementacyjnego i są używane do podkreślenia tego, że system jest implementowany z małych kawałków. Komponent oferuje jeden lub więcej interfejsów zależy jedynie od interfejsów z innymi komponentami. Używanie komponentów pozwala na projektowanie, implementacje, dostawę i zamianę wielu części systemu niezależnie od jego reszty. Elementy modelu projektowego korespondują do komponentów podsystemów, które to są niezależnymi częściami systemu, mogącymi być projektowane i implementowane niezależne. Podsystemy oferują interfejsy i zależą od interfejsów innych elementów modelu. Leszek Grocholski II Uni. Wroc. 18
19 PRZEPŁYW PRACY ( WORKFLOW ) Następny slajd ilustruje w formie diagramu czynności UML, iteracje w przepływie pracy analiza i projektowanie. Każdy stan czynności reprezentuje szczegółowy przepływ pracy np.: Definiowanie kandydującej architektury. Każdy szczegółowy przepływ pracy składa się ze swoich czynności. Niektóre szczegółowe przepływy pracy są zależne od fazy : w iteracjach dot. fazy opracowania definiowana a następnie doskonalona jest architektura, podobnie jest z najważniejszymi obszarami i ryzykami aplikacji są tematem analizy i projektowania. W następującej po niej iteracji fazy budowy, kładziony jest nacisk na dodanie aplikacji większej funkcjonalności w oparciu o coraz bardziej stabilną platformę architektoniczną. Leszek Grocholski II Uni. Wroc. 19
20 wg RUP Leszek Grocholski II Uni. Wroc. 20
21 Definiowanie kandydującej architektury ( Define Candidate Architecture ) * Utworzenie początkowego szkicu architektury systemu. Aktywność definiuje: początkowy zbiór znaczących dla architektury projektowanych elementów ( podstawa analizy ), początkowy zbiór algorytmów analitycznych, początkowe uwarstwienie i organizacja systemu oraz realizacje PU przewidziane do wykonania w danej iteracji. * Zidentyfikowanie klas analitycznych na podstawie znaczących dla architektury przypadków użycia. * Uaktualnianie realizacji PU poprzez analizę współdziałania klas analitycznych. Leszek Grocholski II Uni. Wroc. 21
22 DOSKONALENIE ARCHITEKTURY ( REFINE the ARCHITECTURE ) Ten szczegółowy przepływ pracy składa się z czynności: identyfikowanie zadań i celów projektowych, identyfikowanie elementów, scalanie istniejących elementów projektu, opis architektury czasu rzeczywistego ( opis dystrybucji informacji ), opis wszystkich artefaktów wykonywanych przez architekta, doskonalenie w/w, przegląd architektury wykonywany przez kontrolera projektu. Leszek Grocholski II Uni. Wroc. 22
23 ANALIZA ZACHOWAŃ (ANALYZE BEHAVIOR ) Na ten szczegółowy przepływ pracy składają się następujące czynności: analiza PU przeprowadzona przez projektanta, identyfikacja elementów projektu wykonywana przez architekta systemu i przegląd projektu wykonywany przez kontrolera projektu. Celem tego szczegółowego przepływu pracy jest transformacja opisu zachowań dostarczonego przez PU w zbiór komponentów, które stanowić będą podstawę projektu. Należy zauważyć, że analiza zachowań koncentruje się mniej na niefunkcjonalnych wymaganiach systemu a bardziej na tym bardziej na tym jak zapewnić dostarczenie przez system wymaganych funkcjonalności. Leszek Grocholski II Uni. Wroc. 23
24 Projektowanie Komponentów ( Design Components ) Na ten szczegółowy przepływ pracy składają się czynności: projektowanie PU, projektowanie klas i projektowanie podsystemu, wykonywane przez projektanta komponentów i przegląd projektu wykonywany przez kontrolera projektu. Projektowanie komponentów czasu rzeczywistego ( Design Real Time Components ) Dotyczy projektów które, będą używać jako artefaktów kapsuły pierwszej rangi elementy projektowe w kontekście systemów czasu rzeczywistego. Leszek Grocholski II Uni. Wroc. 24
25 PROJEKTOWANIE BAZY DANYCH ( DESIGN THE DATABASE) Jest to opcjonalny szczegółowy przepływu pracy wymagany, kiedy system korzysta w dużego rozmiaru bazy danych składowanych w bazie danych. Projektowanie bazy danych składa się z następujących działań: projektowanie bazy ( wykonywanej przez projektanta bazy danych), projektowania klas (wykonywanego przez projektanta ), przegląd projektu ( przeprowadzany przez kontrolera projektu ). Leszek Grocholski II Uni. Wroc. 25
26 WSPOMAGANIE NARZĘDZIOWE Modele wykonywane są w UML u. narzędziem tworzenia, zarządzania i prezentacji modeli jest IBM Rational Architect. Architect umożliwia wykonywanie inżynierii wstecz ( round trip engineering ) w paru wybranych językach programowania, zapewnienie perfekcyjnej synchronizacji modeli, kodu różnych wersji systemu od projektowania do kodowania czy na odwrót. IBM Rational Architect dostarcza narzędzi mentorskich w postaci wskazówek do tworzenia modeli w UML i korzystania z systemu. Pakiet Reel Time umożliwia natychmiastowe wykonywanie modeli. Pakiet Soda pozwala na automatyczne generowanie dokumentów czy raportów, ekstrakcje i formatowanie informacji z wielu innych źródeł, takich jak Architect czy Requiste Pro. Leszek Grocholski II Uni. Wroc. 26
27 PODSUMOWANIE Analiza i projektowanie stanowią pomost między wymaganiami a implementacją. Ten przepływ pracy wykorzystują przypadki użycia do identyfikowania zbioru obiektów, który jest sekwencyjnie przekształcany do coraz doskonalszych klas, podsystemów i pakietów. Odpowiedzialności w analizie projektowania są podzielone pomiędzy architekta ( tworzy wielkie obrazy ), projektanta ( szczegóły) projektanta bazy danych ( szczegóły), które wymagają szczegółowej wiedzy o wymaganiach i stanie przedsięwzięcia ( ponowne użycie!). Leszek Grocholski II Uni. Wroc. 27
28 PODSUMOWANIE cd Wynikiem analizy i projektowania jest model projektowy, który może być wyabstrahowany używając 3 perspektywy architektoniczne. Perspektywa logiczna reprezentuje dekompozycje systemu na zbiór logicznych elementów ( klas, podsystemów, pakietów, ich wzajemnych oddziaływań). Perspektywa procesowa ( dynamiczna ) odwzorowywuje te elementy na procesy ( diagram czynności i komunikacji ) oraz wątki w systemie. Perspektywa wdrożeniowe przyporządkowuje realizacje procesy do komponentów oraz do węzłów, w których one działają czy są instalowane. W niektórych przypadkach oddzielny model analityczny może być użyteczny w celu dokonania przeglądu jego funkcji czy zbudowania abstrakcyjnego modelu systemu. Leszek Grocholski II Uni. Wroc. 28
29 INŻYNIERIA OPROGRAMOWANIA Dziękuję za uwagę Leszek Grocholski II Uni. Wroc. 29
Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoProjektowanie Modeli Usług dla rozwiązań typu SOA
Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom
Bardziej szczegółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoRUP. Rational Unified Process
RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną
Bardziej szczegółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoModelowanie i analiza systemów informatycznych
Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.
Bardziej szczegółowoModelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig
Modelowanie Obiektowe Wykład 1: Wprowadzenie do Modelowania i języka UML Anna Kulig Wprowadzenie do modelowania Zasady Pojęcia Wprowadzenie do języka UML Plan wykładu Model jest uproszczeniem rzeczywistości.
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2
Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów
Bardziej szczegółowoAnalityk i współczesna analiza
Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura
Bardziej szczegółowoUML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.
45. UML, jego struktura i przeznaczenie. Przeznaczenie UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. Pozwala obrazować, specyfikować, tworzyć
Bardziej szczegółowoUPEDU: Analiza i projektowanie (ang. analysis and design discipline)
Wydział Informatyki PB Analogia do powstawania kryształu Inżynieria oprogramowania II Wykład 7: UPEDU: Analiza i projektowanie (ang. analysis and design discipline) Marek Krętowski e-mail: mkret@wi.pb.edu.pl
Bardziej szczegółowoWykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
Bardziej szczegółowoUML cz. III. UML cz. III 1/36
UML cz. III UML cz. III 1/36 UML cz. III 2/36 Diagram współpracy Diagramy współpracy: prezentują obiekty współdziałające ze sobą opisują rolę obiektów w scenariuszu mogą prezentować wzorce projektowe UML
Bardziej szczegółowoNarzędzia CASE dla.net. Łukasz Popiel
Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania
Bardziej szczegółowoproblem w określonym kontekście siły istotę jego rozwiązania
Wzorzec projektowy Christopher Alexander: Wzorzec to sprawdzona koncepcja, która opisuje problem powtarzający się wielokrotnie w określonym kontekście, działające na niego siły, oraz podaje istotę jego
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoOpis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Bardziej szczegółowoMichał Adamczyk. Język UML
Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy
Bardziej szczegółowoRozpoczęcie, inicjacja (ang. inception
Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl
Bardziej szczegółowoWykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014
Wykład 4 MIS-1-505-n Inżynieria oprogramowania Październik 2014 Metody Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 4.1 Agenda 1 2 3 Metody Metody 4 5 4.2 Implementacja Metody
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy
Bardziej szczegółowoTutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.
AGH, EAIE, Informatyka Winda - tutorial Systemy czasu rzeczywistego Mirosław Jedynak, Adam Łączyński Spis treści 1 Wstęp... 2 2 Przypadki użycia (Use Case)... 2 3 Diagramy modelu (Object Model Diagram)...
Bardziej szczegółowoTECHNOLOGIE OBIEKTOWE. Wykład 3
TECHNOLOGIE OBIEKTOWE Wykład 3 2 Diagramy stanów 3 Diagram stanu opisuje zmiany stanu obiektu, podsystemu lub systemu pod wpływem działania operacji. Jest on szczególnie przydatny, gdy zachowanie obiektu
Bardziej szczegółowoNazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:
Bardziej szczegółowoUML cz. II. UML cz. II 1/38
UML cz. II UML cz. II 1/38 UML cz. II 2/38 Klasy Najważniejsze informacje o klasie: różnica pomiędzy klasą a jej instancją (obiektem) na podstawie klasy tworzone są obiekty (instancje klasy) stan obiektu
Bardziej szczegółowoModelowanie i Programowanie Obiektowe
Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do
Bardziej szczegółowoSpecyfikowanie wymagań przypadki użycia
Specyfikowanie wymagań przypadki użycia Prowadzący Dr inż. Zofia 1 La1 La2 Forma zajęć - laboratorium Wprowadzenie do laboratorium. Zasady obowiązujące na zajęciach. Wprowadzenie do narzędzi wykorzystywanych
Bardziej szczegółowoAnaliza i projektowanie aplikacji Java
Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie
Bardziej szczegółowoDr Katarzyna Grzesiak-Koped
Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoPodstawy inżynierii oprogramowania
Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane
Bardziej szczegółowoProgramowanie obiektowe
Programowanie obiektowe Laboratorium 11 - przegląd wybranych wzorców mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 24 maja 2017 1 / 38 mgr inż. Krzysztof Szwarc Programowanie obiektowe Wzorce
Bardziej szczegółowoCo to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
Bardziej szczegółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Bardziej szczegółowoUniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013
SYLLABUS na rok akademicki 01/013 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu
Bardziej szczegółowo<Nazwa firmy> <Nazwa projektu> Specyfikacja wymagań projektu. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Bardziej szczegółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowoZakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski
INŻYNIERIA OPROGRAMOWANIA wykład 2: MODELE PROCESU WYTWARZANIA OPROGRAMOWANIA dr inż. Leszek Grocholski ( na podstawie wykładów prof. K. Subiety, Instytut Informatyki PAN ) Zakład Języków Programowania
Bardziej szczegółowo<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoDokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor
Koszalin, 15.06.2012 r. Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor Zespół projektowy: Daniel Czyczyn-Egird Wojciech Gołuchowski Michał Durkowski Kamil Gawroński Prowadzący: Dr inż.
Bardziej szczegółowoKonfiguracja modelowania w procesie wytwarzania oprogramowania
Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów
Bardziej szczegółowoEgzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
Bardziej szczegółowo12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:
Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 1) Oprogramowanie to: 2) Produkty oprogramowania w inżynierii oprogramowania można podzielić na: 3) W procesie wytwarzania oprogramowania
Bardziej szczegółowoKarta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy
Bardziej szczegółowoArchitektura oprogramowania w praktyce. Wydanie II.
Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?
Bardziej szczegółowoWytwarzanie oprogramowania
AiPA 6 Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest procesem przekształcenia wymagań w oprogramowanie zgodnie z metodyką, która określa KTO CO robi JAK i KIEDY. - Wymagania Proces tworzenia
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków
Bardziej szczegółowoOSGi Agata Hejmej 4.05.2009
OSGi Agata Hejmej 4.05.2009 Plan prezentacji Co to jest OSGi Jakie problemy rozwiązuje Opis standardu Przykładowa aplikacja Podsumowanie korzyści Co to jest OSGi? Standard, który pozwala na tworzenie wysoce
Bardziej szczegółowoModel referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami
Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary
Bardziej szczegółowoDiagramy przypadków użycia
Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy
Bardziej szczegółowoDokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Bardziej szczegółowoSOA Web Services in Java
Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy
Bardziej szczegółowoProjekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie
Bardziej szczegółowoInżynieria oprogramowania. Część 5: UML Diagramy klas
UNIWERSYTET RZESZOWSKI KATEDRA INFORMATYKI Opracował: mgr inż. Przemysław Pardel v1.01 2010 Inżynieria oprogramowania Część 5: UML Diagramy klas ZAGADNIENIA DO ZREALIZOWANIA (3H) 1. Diagram klas... 3 Zadanie
Bardziej szczegółowoProjektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Bardziej szczegółowoPodstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Bardziej szczegółowoZdalne monitorowanie i zarządzanie urządzeniami sieciowymi
Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka
Bardziej szczegółowoAnaliza i projektowanie obiektowe w UML Kod przedmiotu
Analiza i owanie obiektowe w UML - opis przedmiotu Informacje ogólne Nazwa przedmiotu Analiza i owanie obiektowe w UML Kod przedmiotu 11.3-WK-MATP-UML-W-S14_pNadGen5M44E Wydział Kierunek Wydział Matematyki,
Bardziej szczegółowoSpis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...
Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników Spis treúci Wstęp... 11 Podziękowania... 13 O autorach... 15 Robert A. Maksimchuk... 15 Eric J. Naiburg... 15 Przedmowa...
Bardziej szczegółowoEtapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Bardziej szczegółowoWPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
Bardziej szczegółowoWzorce Strukturalne. Adapter: opis. Tomasz Borzyszkowski
Adapter: opis Wzorce Strukturalne Tomasz Borzyszkowski Alternatywna nazwa: Wrapper (opakowanie) Rola obiektu Adapter: pełni wobec Klienta rolę otoczki, która umożliwia przetłumaczenie jego żądań na protokół
Bardziej szczegółowoModelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML
VIII Konferencja PLOUG Koœcielisko PaŸdziernik 2002 Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML Piotr Wilk Premium Technology Sp. z o.o. PWilk@PremiumTechnology.pl Modelowanie
Bardziej szczegółowoModel przestrzenny Diagramu Obiegu Dokumentów. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Model przestrzenny Diagramu Obiegu Dokumentów Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Sposoby weryfikacji architektury oprogramowania: - badanie prototypu
Bardziej szczegółowoIBM Rational Software Architect uproszczona instrukcja użytkowania
IBM Rational Software Architect uproszczona instrukcja użytkowania TOMASZ ŁUKASZUK na podstawie Software Developer's Jurnal Extra Nr 18 STRESZCZENIE: Dokument przedstawia ogólne informacje na temat narzędzia
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.
Bardziej szczegółowoJak opisać wymagania zamawiającego wybrane elementy
Jak opisać wymagania zamawiającego wybrane elementy Adam Rzeźnicki, Grzegorz Sobolewski PIIT Listopad, 2012 Agenda Kontekst ma znaczenie - na przykładzie cyklu wytwórczego systemu aplikacyjnego Rodzaje
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.
Bardziej szczegółowoGrupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)
Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej
Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej
Bardziej szczegółowoREQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN
REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoGrupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)
Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne
Bardziej szczegółowoPROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem
PROJEKTOWANIE określenie wymagań specyfikowanie projektowanie kodowanie implementacja testowanie produkt konserwacja Faza strategiczna Analiza Dokumentacja Instalacja PROJEKT most pomiędzy specyfikowaniem
Bardziej szczegółowoKARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20
Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:
Bardziej szczegółowoHistoria modeli programowania
Języki Programowania na Platformie.NET http://kaims.eti.pg.edu.pl/ goluch/ goluch@eti.pg.edu.pl Maszyny z wbudowanym oprogramowaniem Maszyny z wbudowanym oprogramowaniem automatyczne rozwiązywanie problemu
Bardziej szczegółowoProjektowanie logiki aplikacji
Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: moduł specjalności obowiązkowy: Inżynieria oprogramowania Rodzaj zajęć: laboratorium PROJEKT ZESPOŁOWY DYPLOMOWY IO Team Project SE Forma studiów:
Bardziej szczegółowoModelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The
Bardziej szczegółowoWdrożenie technologii procesowej IBM BPM w EFL
Wdrożenie technologii procesowej IBM BPM w EFL Marcin Naliwajko Z-ca dyrektora Departamentu Technologii Dominik Lisowski Starszy Architekt Systemów IT Grupy EFL WebSphere Message Broker 2008 r. Wdrożenie
Bardziej szczegółowoProjektowanie oprogramowania
Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z
Bardziej szczegółowoDokument Detaliczny Projektu
Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej
Bardziej szczegółowoZakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych
Bardziej szczegółowo