Objektumorientált tervezési alapelvek és tervezési minták döntésalapú elemzése, a döntésösszevonás elmélete és gyakorlata
| dc.contributor.advisor | Terdik, György | |
| dc.contributor.author | Márien, Szabolcs | |
| dc.contributor.department | Informatikai tudományok doktori iskola | hu |
| dc.contributor.submitterdep | DE--TEK--Informatikai Kar -- Információ Technológia Tanszék | |
| dc.contributor.submitterdep | DE--TEK--Informatikai Kar -- Információ Technológia Tanszék | |
| dc.contributor.submitterdep | DE--TEK--Informatikai Kar -- Információ Technológia Tanszék | |
| dc.contributor.submitterdep | DE--TEK--Informatikai Kar -- Információ Technológia Tanszék | |
| dc.date.accessioned | 2012-06-08T10:55:08Z | |
| dc.date.available | 2012-06-08T10:55:08Z | |
| dc.date.created | 2011 | hu_HU |
| dc.date.defended | 2012-06-22 | |
| dc.description.abstract | Észrevételem szerint a tervezési alapelvek és tervezési minták legfontosabb célja az implementációs függőségek típusain belül a különböző döntésszerkezetek szerinti döntésredundanciák, mint egyfajta implementációs függőségek feloldása. Nem megfelelően implementált, redundáns döntések implementációs függőségeket eredményeznek, melyeket döntésszerkezeti implementációs függőségnek nevezek. A programban lévő döntések során arról döntünk, hogy egy adott ponton milyen funkcionalitásra és/vagy adatszerkezetre van szükségünk. Amikor egy döntést definiálunk a döntés döntéslehetőségeinek funkcionalitását és/vagy adatszerkezetét adjuk meg. A döntéslehetőségen a döntés egy lehetséges kimenetelét értjük, amely a döntéslehetőségnek megfelelő funkcionalitás és/vagy adatstruktúra érvényre jutását jelenti, illetve a döntéslehetőség teljesülését jelentő döntéspredikátumot, ami alapján eldől, hogy egy adott döntési helyen melyik döntéslehetőség jut érvényre. Ahhoz, hogy a döntésredundanciák feloldásának lehetőségeit megértsük az objektumorientált módszertan alapeszközének, az öröklődésnek az értelmezését kell kiterjeszteni: Az öröklődés a programban lévő döntésredundanciák feloldásának eszköze, amely a döntések összevonása és kiemelése után azok deklarációjára ad egy absztraktabb keretet. Ezzel természetesen a többi objektumorientált alapfogalom is más megközelítésbe kerül. A refaktorálás, mint a kód minőségjavítás módszere, foglalkozik a döntésstruktúrák osztály-alosztály kapcsolatokba történő kiemelésének lehetőségeivel; ugyanakkor nem részletezi a döntésredundanciák esetei szerinti döntésösszevonások lehetőségeit, melyet dolgozatom egyik eredményeként a döntésstruktúrák refaktorálással történő optimalizálásának fő lehetőségének gondolok. A programokban lévő döntésismétlődések megszüntetésére a döntések osztályhierarchiákba történő kiemelésével vagy már kiemelt döntések összevonásával van lehetőség, amely után a döntések lehetőségeihez tartozó adattartalmak és funkcionalitások egy osztály alosztályaiban kapnak keretet. Tehát a döntésösszevonás lehetőségét megadó döntéskiemelés során a döntés definíciót egy absztraktabb formában, azaz egy osztályhierarchiában adjuk meg, ahol a döntés „felületét” egy polimorf metódus jelenti. Kiemelve a döntéseket és a döntéslehetőségeket egy osztályba és annak alosztályaiba, a megfelelő döntésösszevonásokat elvégezve lehetővé válik, hogy a döntéseket egy helyen meghozva, annak eredményét a kiemeléskor, összevonáskor megadott osztályba és annak alosztályaiba „zárva” (példányosítás) archiváljuk. A létrejövő objektumot egy referencia változóval hivatkozzuk, amely típusa a szülőosztály. Az adott döntés további döntési pontjain már a meghozott, archivált döntés eredményét – szülőosztály típusú referencia típusú változót használhatjuk fel úgy, hogy nem kell figyelni arra, hogy a döntés során mely döntéslehetőség érvényesült, azaz melyik alosztályt példányosítottuk, hiszen a szülőosztály típusával hivatkozva a későbbi felhasználások során rejtve, bezárva marad, mivel a döntés felületét egy polimorf metódus adja. A döntéseknek két állapotát különböztetjük meg attól függően, hogy az adott döntés definiálása, azaz a döntéslehetőségek adatstruktúrái, metodológiája egy metódusban van-e megadva vagy már kiemelten egy osztályban és annak alosztályaiban. Meghatározom azokat a döntésszerkezeti jellemzőket, amelyek esetén a döntésredundanciák megszűntetése indokolja a döntésösszevonásokat. A döntésösszevonások megfogalmazott esetei kulcsfontosságúak a döntésszerkezetek alapján javasolt tervezési alapelvek és metrikák, tervezési minták jellemzői szempontjából. Megfogalmazok két új tervezési alapelvet. Az első alapelv – „Öröklődést döntésredundanciák megszűntetésére használjunk!” – egyértelműen meghatározza azon eseteket, amikor az öröklődés, mint objektumorientált eszköz használata az objektumösszetétellel szemben indokolt lehet. Mivel a már meglévő tervezési alapelvek egy kritikus pontja annak eldöntése, hogy az öröklődés használata mely esetekben indokolt, ezért az új elv lényeges kiegészítést jelent a már meglévő alapelvek tekintetében. A döntésredundanciák csökkentése, mint új cél elérése érdekében megfogalmazott másik új alapelv: „A döntésredundanciákat kerüljük!”. Az elképzelésnek megfelelően az objektumorientált alapeszközök és a már meglévő tervezési alapelvek értelmezését is kiegészítem, amely alapján a tervezési alapelvek céljaival összhangban levő tervezési minták céljai, leírásai is változnak. Olyan új objektumorientált metrikákat vezetek be, melyekkel lehetőség van a programban szereplő döntésredundanciák mértékének megállapítására, illetve, melyekkel a bevezetett tervezési alapelvek teljesülése mérhető. („Döntésabsztrakciós metrika”, „Döntéskiemeléssel létrejött öröklődések aránya”, „Ekvivalens döntésesetek aránya”, „Döntéspredikátumában eltérő egyéb viselkedésében egyező döntésesetek aránya”, „Ekvivalens döntéspredikátumú döntésesetek aránya” metrikák) A tervezési minták új értelmezés szerinti célja a jól strukturáltság elérése a döntésismétlődések megszűntetésével. Tehát a tervezési minták a döntéskiemelésekre adnak recepteket, vagyis arra, hogy a különböző strukturált döntési helyzetekben a döntésismétlődés megszüntetése miként biztosítható. A tervezési minták osztályozhatók aszerint, hogy milyen döntésszerkezetek esetén adják meg az optimális döntésdeklarációkat, illetve, hogy a döntésarchiválás mely módját támogatják. A tervezési minták alkalmazásának egy új irányát vehetjük észre, miszerint a döntések nem kiemelt állapota esetén is észlelhetők azok a döntéskapcsolatok, amelyek az adott tervezési mintára jellemzőek, így a tervezési minták nem csak a jelenlegi formájukban ismerhetők fel, hanem a döntések nem kiemelt állapota esetén a tervezési minták „lenyomatai” is észlelhetők. Ez új lehetőséget ad annak tisztázására, hogy milyen esetekben lehetséges egy adott tervezési minta felhasználása, hiszen egy tervezési minta leírásakor nem egy optimális megoldás paramétereit kell, hogy megadjuk, hanem egy olyan tervezési helyzet körülményeit, amikor egy adott tervezési minta felhasználásával egy optimálisabb struktúra kialakítása érhető el. Tehát a tervezési minták bevezetésének lehetősége sokkal érthetőbbé válik, mivel konkrét megoldástól független jellemzők, a döntésszerkezet szerint határozható meg egy tervezési minta alkalmazhatósága. Abban az esetben, ha a döntések elemzése automatizált eszközökkel is megtehető, akkor lehetőség nyílhat a tervezési minta alkalmazás szükségességének automatikus felismerésére. Hogy az elképzelésnek megfelelően a strukturáltságot, azaz a jól strukturált program irányelveinek teljesülését elemezni tudjuk, szükséges egy olyan formalizációs eszköz, amellyel a döntések viselkedése vizsgálható. Erre a Java programok viselkedés interfész specifikációs nyelvét, a JML-t használom, amely lehetőséget ad a döntés lehetőségeinek adatstruktúráját, metodológiáját logikai kifejezésekre alapozva specifikálni. Az így formalizált döntések vizsgálata a döntésösszevonás szabályai szerint már lehetséges. A JML alapú döntésspecifikációra alapozva a tervezési mintákat jellemző döntésszerkezet is modellezhető. A „Híd” tervezési mintában található döntésszerkezet deklarációk különböző állapotainak formális leírását külön-külön adom meg, amely alapján megfogalmazom azokat az általános szabályokat, amelyek a JML-es döntésszerkezet szerinti tervezési minta formalizálás alapjai lehetnek. Az elgondolás helyességének vizsgálataként az elmúlt másfél évben folyó „eFilter” kutatás-fejlesztéses projekt projektvezetőjeként és vezető tervezőjeként a tervezési fázisában kezdeményeztem, hogy a tervezési minták alkalmazhatóságát a döntésszerkezetek elemzésével végezzük, mely során számos komplex tervezési problémára sikerült optimális megoldást találni. A projekt során a döntésszerkezetek – tervezési minták összefüggéseinek egy új irányát sikerült felfedezni, miszerint a tervezési mintákra jellemző döntési helyzetek már a használati eset modellekben is megjelennek. Új kutatási irány ennek megfelelően az, hogy a tervezési minták a használati eset modellekben miként jelennek meg, illetve hogy a tervezési minták döntésszerkezetei hogyan tükröződnek a használati esetek szintjén. As I noticed, the most important goal of design patterns and design principles is the elimination of the decision structure based redundancies as a kinds of implementation dependencies. The not properly implemented, redundant decisions result in implementation dependencies, which are called decision structure implementation dependencies. During the decisions in the application, we decide about the functionality and/or data structure needed at a given point. When we define a decision, we give the functionality and/or data structure of the decision’s decision options. By decision option, we mean one possible outcome of a decision, which means the enforcing of the functionality and/or data structure appropriate for the decision option, and the decision predicate which decides which decision option will set off at a given decision location. In order to understand the options of dissolving the decision redundancies, we need to extend the basic concept of object-oriented methodology, the inheritance: The inheritance is the tool to dissolve the decision redundancies in the software, which gives a more abstract framework to declare decisions after their contraction and raising. With this, all the other basic concepts of object-oriented programming change as well. Refactoring, as the tool of improving the quality of the code, handles the options of raising the decision structures into class-subclass relations, but in the same time, it does not detail the options of decision contraction according to the cases of decision redundancies, that, as a result of my thesis, I think to be the main option of optimizing the decision structures by refactoring. To extinguish the decision-recurrence in softwares, we have the option to organize the decisions into class hierarchies or to contract the already organized decisions, after which the data that belongs to the decisions’ options and functionalities will get a frame in a class’ subclasses. So during the decision-raising that gives the opportunity of the decision-contraction, the decision definition is given in a more abstract form, namely in a class hierarchy, where the “surface” of the decision is meant by a polymorph method. By raising the decisions and decision options into a class and it’s subclasses, than executing the appropriate decision contractions, it becomes possible to make the decision in one place and to archive it by closing the results into the same class and it’s subclasses given during the raising and contraction (instantiating). The object created this way is referenced with a reference variable which’s type is the parent class. On the further decision locations of the given decision we can use the result of archived decision – as a variable with a reference type and parent class type – in a way that we do not need to check what decision option was enforced during the decision, namely which subclass had been instantiated, because it remains hidden and closed during further usage as it is referenced with it’s parent class because the surface of the decision is given by a polymorph method. We differentiate two states of the decisions depending on that if defining the given decision, namely the data structures, methodology of the decision options are given in one method, or are raised to a class and it’s subclasses. I appoint those decision structure parameters, when the elimination of the decision redundancies justifies the decision-contractions. The defined cases of decision-contractions are the keys to the parameters of the design patterns, the designing principles and metrics suggested by the decision structures. metrics. I formulate two new design principles. The first principle – “Inheritance is used dissolve decision redundancies.” – clearly identifies those cases, when the usage of inheritance as object-oriented tool is reasonable over against object composition. As one of the critical points of the existing design principles is the decision of when is the use of inheritance justified, the new principle means a significant supplement in point of the extant principles. In favour of the diminishing of the decision redundancies, as an achievable new goal, the other new principle is the following: “Avoid decision redundancies.” According to the concept, I also expand the interpretation of the basic object-oriented paradigms and the existing design principles, under which the goals and descriptions of the design patterns in consort with the goals of the design principles will change to. I initiate such new object-oriented metrics, that gives opportunity to determine the degree of decision-redundancies in the software, or rather, with which the fulfillment of the initiated design principles is measurable. (The “Ratio of equivalent decision cases”, „Ratio of decision cases different in their decision predicate but the same in any other behavior”, „Ratio of decision cases with equivalent decision predicate” “Ratio of inheritances coming into existence by decision-raising”, “Metrics of Decision-abstraction” metrics.) The goal of design patterns according to the new presentation is to achieve a well-structured program by dissolving decision recurrences. So the design patterns give a recipe for decision-raising, or rather to that how can the decision recurrences be avoided in different structured decision situations. The design patterns are classifiable by in what cases of decision structures do they give the optimal decision-declarations, or rather what kind of decision archiving method do they support. We can notice a new way in using the design patterns, that the decision-structures that are typical to the given design pattern can be noticed even if the decision is not in a raised state, hence the design patterns are not only recognizable in their current form, but the “imprints” of the designing patterns can be noticed in the non-raised state of the decisions. This gives a new opportunity to clarify in what cases is the usage of a given design pattern is possible, as when describing a design pattern we do not need to give the parameters of an optimal solution, but the circumstances of design situation, when by using the given design pattern a more optimal structure can be developed. Thus the possibility of initiating the design patterns become more understandable, as the applicability of a design pattern can be determined by parameters independent of the factual solution, which is according to the decision structure. In the case when the analysis of the decision can be done by automated tools, it may be possible to automatically realize the need of using a design pattern. As to be able to analyze, according to the idea, verify the structuredness, namely the fulfillment of the principles of a well-structured software, we need a formalization tool that can be used to examine the behavior of decisions. For this, I use the behavior interface specification language of the Java applications, the JML, that enables to specify the data structure, methodology of the decisions’ options based on logical expressions. The examination of the decisions formalized in this manner is now possible according to the rules of decision-contraction. Built upon the JML-based decision specification, the decision structure describing the design patterns can be modeled to. I give the formal descriptions of the different states of the decision structure declarations found in the design pattern one by one, by which I formulate those general rules, that can be the basics of the design pattern formalization according to the JML decision structure. As the examination of the conception’s correctness, as project leader and lead designer of the eFilter research-expansion project going on in the last one and a half year, in the design phase I initiated that the design patterns’ applicability be analyzed by the decision structures, during which we have managed to find optimal solution for many complex designing problems. During the project, I have managed to discover a new direction in the connection of the decision structures and design patterns, that the design patterns yet appear in the use case models based on decision situations. According to this, the new research direction is to find out how does the design patterns appear in the use case models, or rather how does the decision structures of the designing patterns reflect on the level of use cases. | hu_HU |
| dc.format.extent | 177 | hu_HU |
| dc.identifier.uri | http://hdl.handle.net/2437/129976 | |
| dc.language.iso | hu | hu_HU |
| dc.language.iso | en | hu_HU |
| dc.subject | Objektumorientált tervezési alapelv | hu_HU |
| dc.subject | Object-oriented design principle | hu_HU |
| dc.subject | JML | |
| dc.subject | Tervezési minta | |
| dc.subject | Metrika | |
| dc.subject | Design pattern | |
| dc.subject | Metric | |
| dc.subject.discipline | Informatikai tudományok | hu |
| dc.subject.sciencefield | Műszaki tudományok | hu |
| dc.title | Objektumorientált tervezési alapelvek és tervezési minták döntésalapú elemzése, a döntésösszevonás elmélete és gyakorlata | hu_HU |
| dc.title.translated | Decision Based Interpretation of Object-Oriented Design Principles and Design Patterns, Decision Contraction Theory with Practice | hu_HU |