Объектіге бағытталған талдау және жобалау әдістемелері
Object-oriented analysis and design
Бағдарламалық жасақтама әзірлеу әдістемесі: Объектіге бағытталған талдау (OOAD) жүйе құру, сапаны арттыру және қатысушылармен байланыс үшін қолданылады. Жаңартулар бизнес-құндылыққа негізделген.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Бағдарламалық жасақтаманы әзірлеу әдістемесі
Software development methodology
Объектіге бағытталған талдау және жобалау (OOAD) – бағдарламалық жасақтаманы әзірлеу процесінде объектіге бағытталған бағдарламалауды қолдану арқылы, сондай-ақ мүдделі тараптармен байланыс пен өнім сапасын жақсарту үшін визуальды модельдеуді пайдалану арқылы қосымшаны, жүйені немесе бизнесті талдау мен жобалауға арналған техникалық тәсіл. Қазіргі заманғы бағдарламалық жасақтама инженериясында OOAD әдетте итеративтік және инкременттік жолмен жүзеге асырылады. OOAD шараларының нәтижесі – талдау модельдері (OOA үшін) және жобалау модельдері (OOD үшін) болып табылады. Бұл модельдер тәуекелдер мен бизнес құндылығы сияқты маңызды факторларға байланысты үнемі жетілдіріліп, дамытылуға тиіс.
Object oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality. OOAD in modern software engineering is typically conducted in an iterative and incremental way. The outputs of OOAD activities are analysis models (for OOA) and design models (for OOD) respectively. The intention is for these to be continuously refined and evolved, driven by key factors like risks and business value.
Тарих
1990 жылдардың ортасына дейінгі объектіге бағытталған технологияның алғашқы кезеңдерінде бағдарламалық жасақтаманы әзірлеу және объектіге бағытталған модельдеу үшін көптеген әртүрлі бәсекелес әдістемелер болды, олар көбінесе нақты Компьютерлік көмекші бағдарламалық жасақтама инженериясы (CASE) құралдарын жеткізушілермен байланысты болды. Ол кездегі басты мәселе стандартты нотациялардың, біркелкі терминдердің және процестік нұсқаулардың болмауы еді, бұл коммуникация тиімділігін төмендетіп, оқу қисығын ұзартты. Белгілі бір ерте объектіге бағытталған әдістемелер Грейди Бух, Джеймс Румбо, Ивар Джейкобсон (Үш дос), Роберт Мартин, Питер Коад, Салли Шлеер, Стивен Меллор және Ребекка Вирфс Брок сияқты сарапшылардан бастау алды және олардың ықпалымен дамыды. 1994 жылы Rational Software компаниясының Үш досы бірігіп Бірыңғай модельдеу тілін (UML) әзірлеу жұмысын бастады. Кейіннен Филипп Крухтен және Уокер Ройс (Уинстон Ройстің үлкен ұлы) қосылып, өз әдістемелерін – OMT, OOSE және Booch әдісін, сондай-ақ басқа да сала жетекшілерінің түрлі көзқарастары мен тәжірибелерін Rational Unified Process (RUP) – бағдарламалық жасақтаманы әзірлеу және жобаны басқару саласындағы ең жақсы тәжірибелерді оқып үйренуге арналған кешенді итеративті және инкрементті процестік нұсқаулық пен құрылымға біріктіруде табысқа жетті. Осыдан бері Бірыңғай процесс отбасы объектіге бағытталған талдау және жобалау үшін ең танымал әдістеме және эталондық модельге айналды.
In the early days of object oriented technology before the mid 1990s, there were many different competing methodologies for software development and object oriented modeling, often tied to specific Computer Aided Software Engineering (CASE) tool vendors. No standard notations, consistent terms and process guides were the major concerns at the time, which degraded communication efficiency and lengthened learning curves. Some of the well known early object oriented methodologies were from and inspired by gurus such as Grady Booch, James Rumbaugh, Ivar Jacobson (the Three Amigos), Robert Martin, Peter Coad, Sally Shlaer, Stephen Mellor, and Rebecca Wirfs Brock. In 1994, the Three Amigos of Rational Software started working together to develop the Unified Modeling Language (UML). Later, together with Philippe Kruchten and Walker Royce (eldest son of Winston Royce), they have led a successful mission to merge their own methodologies, OMT, OOSE and Booch method, with various insights and experiences from other industry leaders into the Rational Unified Process (RUP), a comprehensive iterative and incremental process guide and framework for learning industry best practices of software development and project management. Since then, the Unified Process family has become probably the most popular methodology and reference model for object oriented analysis and design.
Шолу
Бағдарламалық жасақтаманың өмірлік циклы әдетте проблеманың абстрактілі сипаттамаларынан бастап, жобалауға, содан кейін кодтау мен сынаққа және соңында іске қосуға дейінгі кезеңдерге бөлінеді. Бұл процестің алғашқы кезеңдері – талдау және жобалау. Талдау кезеңі көбінесе «талаптарды жинау» деп аталады. Бағдарламалық жасақтаманы әзірлеудің кейбір тәсілдерінде – жалпы алғанда «суарна модельдері» деп аталады – әр кезеңнің арасындағы шекаралар өте қатаң және тізбекті болып табылады. «Суарна» термині мұндай әдістемелерде прогресс тек бір бағытта, яғни тізбекпен жүретінін көрсету үшін қолданылды, атап айтқанда, талдау аяқталғаннан кейін ғана жобалау басталады және дизайн мәселесі талдау моделін өзгертуді талап еткенде немесе кодтау мәселесі дизайнды өзгертуді талап еткенде бұл сирек кездеседі (және қателік көзі саналады). Суарна модельдеріне альтернатива – итеративтік модельдер. Бұл айырмашылықты Барри Боем өзінің итеративтік бағдарламалық жасақтаманы дамытуға арналған спиральді моделі туралы өте ықпалды мақаласында танымал етті. Итеративтік модельдерде модельдің әртүрлі кезеңдерінде параллель жұмыс істеу мүмкін. Сонымен, мысалы, бір күні талдау, жобалау және тіпті кодтау бойынша жұмыс істеу мүмкін және бұл қателік көзі ретінде қарастырылмайды, ал бір кезеңдегі мәселелер екінші кезеңдегі мәселелерге әсер етеді. Итеративтік модельдерге баса назар аудару – бағдарламалық жасақтаманы дамыту білімді талап ететін процесс және талдау сияқты нәрселерді дизайн мәселелерін түсінбестен толыққанды түсіну мүмкін емес, кодтау мәселелері дизайнға әсер етуі мүмкін, сынақ кодты немесе тіпті дизайнды қалай өзгерту керектігі туралы ақпарат бере алады. Объектіге бағытталған дамуды суарна модельін пайдалану арқылы жүзеге асыру мүмкін болғанымен, практикада көптеген объектіге бағытталған жүйелер итеративтік тәсілмен дамытылады. Нәтижесінде, объектіге бағытталған процестерде «талдау және жобалау» көбінесе бір уақытта қарастырылады. Объектіге бағытталған парадигма модулділік пен қайта пайдалануға баса назар аударады. Объектіге бағытталған тәсілдің мақсаты – «ашық-жабық принципті» қанағаттандыру. Модуль, егер ол кеңейтуді қолдаса немесе модуль жаңа мінез-құлықты қосудың немесе жаңа күйлерді сипаттаудың стандартталған тәсілдерін ұсынса, ашық болып саналады. Объектіге бағытталған парадигмада бұл көбінесе қолданыстағы кластың жаңа қосалқы класын құру арқылы жүзеге асырылады. Модуль, егер ол барлық басқа модульдер пайдаланатын және бір модульге екінші модульдегі өзгерістер арқылы енгізілетін өзара әрекеттесуді және ықтимал қателерді шектейтін жақсы анықталған тұрақты интерфейске ие болса, жабық болып саналады. Объектіге бағытталған парадигмада бұл объектілердегі қызметтерді шақыратын әдістерді анықтау арқылы жүзеге асырылады. Әдістер қоғамдық немесе жеке болуы мүмкін, яғни объектке тән белгілі бір мінез-құлық басқа объектілерге ашылмауы мүмкін. Бұл компьютерлік бағдарламалаудағы көптеген жалпы қателердің көзін азайтады. Бағдарламалық жасақтаманың өмірлік циклы әдетте проблеманың абстрактілі сипаттамаларынан бастап, жобалауға, содан кейін кодтау мен сынаққа және соңында іске қосуға дейінгі кезеңдерге бөлінеді. Бұл процестің алғашқы кезеңдері – талдау және жобалау. Талдау мен жобалау арасындағы айырмашылық көбінесе «не» және «қалай» деп сипатталады. Талдау кезінде әзірлеушілер пайдаланушылармен және домен сарапшыларымен жүйенің не істеу керектігін анықтау үшін жұмыс істейді. Бұл кезеңде іске асырудың егжей-тегжейлері көбінесе немесе толығымен (нақты әдіске байланысты) ескерілмейді. Талдау кезеңінің мақсаты – тиісті технология сияқты шектеулерге қарамастан жүйенің функционалдық моделін құру. Объектіге бағытталған талдауда бұл әдетте пайдалану жағдайлары және ең маңызды объектілердің абстрактілі анықтамалары арқылы жасалады. Келесі жобалау кезеңінде талдау моделі жетілдіріледі және қажетті технология мен басқа да іске асыру таңдаулары жасалады. Объектіге бағытталған дизайнда әртүрлі объектілерді, олардың деректерін, мінез-құлқын және өзара әрекеттесуін сипаттауға басымдық беріледі. Жобалау моделінде бағдарламашылар кодта жобаны жүзеге асыруға қажетті барлық егжей-тегжейлі мәліметтер болуы керек.
The software life cycle is typically divided up into stages, going from abstract descriptions of the problem, to designs, then to code and testing, and finally to deployment. The earliest stages of this process are analysis and design. The analysis phase is also often called "requirements acquisition". In some approaches to software development—known collectively as waterfall models—the boundaries between each stage are meant to be fairly rigid and sequential. The term "waterfall" was coined for such methodologies to signify that progress went sequentially in one direction only, i. e., once analysis was complete then and only then was design begun and it was rare (and considered a source of error) when a design issue required a change in the analysis model or when a coding issue required a change in design. The alternative to waterfall models are iterative models. This distinction was popularized by Barry Boehm in a very influential paper on his Spiral Model for iterative software development. With iterative models it is possible to do work in various stages of the model in parallel. So for example it is possible—and not seen as a source of error—to work on analysis, design, and even code all on the same day and to have issues from one stage impact issues from another. The emphasis on iterative models is that software development is a knowledge intensive process and that things like analysis can't really be completely understood without understanding design issues, that coding issues can affect design, that testing can yield information about how the code or even the design should be modified, etc. Although it is possible to do object oriented development using a waterfall model, in practice most object oriented systems are developed with an iterative approach. As a result, in object oriented processes "analysis and design" are often considered at the same time. The object oriented paradigm emphasizes modularity and re usability. The goal of an object oriented approach is to satisfy the "openclosed principle". A module is open if it supports extension, or if the module provides standardized ways to add new behaviors or describe new states. In the object oriented paradigm this is often accomplished by creating a new subclass of an existing class. A module is closed if it has a well defined stable interface that all other modules must use and that limits the interaction and potential errors that can be introduced into one module by changes in another. In the object oriented paradigm this is accomplished by defining methods that invoke services on objects. Methods can be either public or private, i. e., certain behaviors that are unique to the object are not exposed to other objects. This reduces a source of many common errors in computer programming. The software life cycle is typically divided up into stages going from abstract descriptions of the problem to designs then to code and testing and finally to deployment. The earliest stages of this process are analysis and design. The distinction between analysis and design is often described as "what vs. how". In analysis developers work with users and domain experts to define what the system is supposed to do. Implementation details are supposed to be mostly or totally (depending on the particular method) ignored at this phase. The goal of the analysis phase is to create a functional model of the system regardless of constraints such as appropriate technology. In object oriented analysis this is typically done via use cases and abstract definitions of the most important objects. The subsequent design phase refines the analysis model and makes the needed technology and other implementation choices. In object oriented design the emphasis is on describing the various objects, their data, behavior, and interactions. The design model should have all the details required so that programmers can implement the design in code.
Нысанға бағдарланған талдау
Бағдарламалық жасақтаманың өмірлік циклындағы кез келген талдау қызметінің мақсаты – іске асыру шектеулеріне тәуелсіз жүйенің функционалдық талаптарының моделін құру. Объектіге бағытталған талдау мен басқа талдау түрлерінің арасындағы басты айырмашылық – объектіге бағытталған тәсілмен біз талаптарды объектілердің айналасында ұйымдастырамыз, олар жүйе өзара әрекеттесетін нақты әлемдегі объектілерге сәйкес келетін мінез-құлқы (процестерді) және күйін (деректерді) біріктіреді. Басқа немесе дәстүрлі талдау әдістемелерінде процестер мен деректер екі бөлек аспект ретінде қарастырылады. Мысалы, деректер ER-диаграммалармен, ал мінез-құлық ағын диаграммаларымен немесе құрылым диаграммаларымен моделенуі мүмкін. Объектіге бағытталған талдауда (ООА) қолданылатын негізгі модельдер – қолдану жағдайлары мен объектілер модельдері. Қолдану жағдайлары жүйе орындауы тиіс стандартты домендік функциялардың сценарийлерін сипаттайды. Объектілер модельдері атауларды, класс қатынастарын (мысалы, шеңбер – пішіннің кіші классы), операцияларды және негізгі объектілердің қасиеттерін сипаттайды. Пайдаланушы интерфейсінің макеттері немесе прототиптері түсінуді жеңілдету үшін жасалуы мүмкін.
The purpose of any analysis activity in the software life cycle is to create a model of the system's functional requirements that is independent of implementation constraints. The main difference between object oriented analysis and other forms of analysis is that by the object oriented approach we organize requirements around objects, which integrate both behaviors (processes) and states (data) modeled after real world objects that the system interacts with. In other or traditional analysis methodologies, the two aspects: processes and data are considered separately. For example, data may be modeled by ER diagrams, and behaviors by flow charts or structure charts. Common models used in OOA are use cases and object models. Use cases describe scenarios for standard domain functions that the system must accomplish. Object models describe the names, class relations (e. g. Circle is a subclass of Shape), operations, and properties of the main objects. User interface mockups or prototypes can also be created to help understanding.
Нысанға бағдарланған жобалау
Объектіге бағытталған жобалау (ОБЖ) кезінде әзірлеуші, объектіге бағытталған талдауда құрылған түсінік модельге іске асыру шектеулерін қолданады. Мұндай шектеулерге аппараттық және бағдарламалық платформалар, өнімділік талаптары, тұрақты сақтау және транзакциялар, жүйенің қолдануға ыңғайлылығы, сондай-ақ бюджет және уақыт шектеулері жатуы мүмкін. Технологияға тәуелсіз талдау моделіндегі түсініктер іске асыру кластары мен интерфейстерге бейімделеді, нәтижесінде шешім доменінің моделі пайда болады, яғни жүйені нақты технологиялар негізінде қалай құру керектігінің толық сипаттамасы. ОБЖ кезінде маңызды тақырыптарға архитектуралық және жобалау үлгілерін қолдану арқылы бағдарламалық архитектураны жобалау, сондай-ақ объектіге бағытталған жобалау принциптері де кіреді.
During object oriented design (OOD), a developer applies implementation constraints to the conceptual model produced in object oriented analysis. Such constraints could include the hardware and software platforms, the performance requirements, persistent storage and transaction, usability of the system, and limitations imposed by budgets and time. Concepts in the analysis model which is technology independent, are mapped onto implementing classes and interfaces resulting in a model of the solution domain, i. e., a detailed description of how the system is to be built on concrete technologies. Important topics during OOD also include the design of software architectures by applying architectural patterns and design patterns with the object oriented design principles.