Building scalable software systems in the multicore era

Software systems must face two challenges today: growing complexity and increasing parallelism in the underlying computational models. The problem of increased complexity is often solved by dividing systems into modules in a way that permits analysis of these modules in isolation. The problem of lack of concurrency is often tackled by dividing system execution into tasks that permits execution of these tasks in isolation. The key challenge in software design is to manage the explicit and implicit dependence between modules that decreases modularity. The key challenge for concurrency is to manage the explicit and implicit dependence between tasks that decreases parallelism. Even though these challenges appear to be strikingly similar, current software design practices and languages do not take advantage of this similarity. The net effect is that the modularity and concurrency goals are often tackled mutually exclusively. Making progress towards one goal does not naturally contribute towards the other. My position is that for programmers that are not formally and rigorously trained in the concurrency discipline the safest and most productive way to get scalability in their software is by improving modularity of their software using programming language features and design practices that reconcile modularity and concurrency goals. I briefly discuss preliminary efforts of my group, but we have only touched the tip of the iceberg

Світанок освіти з інженерії програмного забезпечення

Designing a mobile-oriented environment for professional and practical training requires determining the stable (fundamental) and mobile (technological) components of its content and determining the appropriate model for specialist training. In order to determine the ratio of fundamental and technological in the content of software engineers’ training, a retrospective analysis of the first model of training software engineers developed in the early 1970s was carried out and its compliance with the current state of software engineering development as a field of knowledge and a new the standard of higher education in Ukraine, specialty 121 “Software Engineering”. It is determined that the consistency and scalability inherent in the historically first training program are largely consistent with the ideas of evolutionary software design. An analysis of its content also provided an opportunity to identify the links between the training for software engineers and training for computer science, computer engineering, cybersecurity, information systems and technologies. It has been established that the fundamental core of software engineers’ training should ensure that students achieve such leading learning outcomes: to know and put into practice the fundamental concepts, paradigms and basic principles of the functioning of language, instrumental and computational tools for software engineering; know and apply the appropriate mathematical concepts, domain methods, system and object-oriented analysis and mathematical modeling for software development; put into practice the software tools for domain analysis, design, testing, visualization, measurement and documentation of software. It is shown that the formation of the relevant competencies of future software engineers must be carried out in the training of all disciplines of professional and practical training.Проектування мобільного орієнтованого середовища для професійної та практичної підготовки вимагає визначення стійких (фундаментальних) та мобільних (технологічних) компонентів його змісту та визначення відповідної моделі підготовки фахівців. З метою визначення співвідношення фундаментального та технологічного у змісті підготовки фахівців з інженерії програмного забезпечення було проведено ретроспективний аналіз першої моделі підготовки фахівців з інженерії програмного забезпечення , розробленої на початку 1970-х років, та її відповідність поточному стану розробки інженерії програмного забезпечення як галузь знані та новому стандарт вищої освіти в Україні, спеціальність 121 «Інженерія програмного забезпечення». Визначено, що послідовність та масштабованість, притаманна історично першій програмі підготовки, значною мірою відповідає ідеям еволюційного проектування програмного забезпечення. Аналіз її змісту також дав можливість виявити зв’язок між навчанням фахівців з інженерії програмного забезпечення та навчанням фахівців з інформатики, комп'ютерної інженерії, кібербезпеки, інформаційних систем та технологій. Встановлено, що основне ядро підготовки фахівців з інженерії програмного забезпечення повинно забезпечувати досягнення студентами таких провідних результатів навчання: знати та впроваджувати на практику основні поняття, парадигми та основні принципи функціонування мови, інструментальні та обчислювальні засоби для інженерії програмного забезпечення ; знати та застосовувати відповідні математичні концепції, доменні методи, системний та об’єктно-орієнтований аналіз та математичне моделювання для розробки програмного забезпечення; реалізувати на практиці програмні засоби для аналізу домену, проектування, тестування, візуалізації, вимірювання та документуваггя програмного забезпечення. Показано, що формування відповідних компетенцій майбутніх фахівців з інженерії програмного забезпечення повинно здійснюватися при підготовці всіх дисциплін професійної та практичної підготовки

Quantitative prediction of quality attributes for component-based software architectures

+297hlm.;24c

Concurrency by modularity: Design patterns, a case in point

General purpose object-oriented programs typically aren’t embarrassingly parallel. For these applications, finding enough concurrency remains a challenge in program design. To address this challenge, in the Pā¯nini project we are looking at reconciling concurrent program design goals with modular program design goals. The main idea is that if programmers improve the modularity of their programs they should get concurrency for free. In this work we describe one of our directions to reconcile these two goals by enhancing Gang-of-Four (GOF) object-oriented design patterns. GOF patterns are commonly used to improve the modularity of object-oriented software. These patterns describe strategies to decouple components in design space and specify how these components should interact. Our hypothesis is that if these patterns are enhanced to also decouple components in execution space applying them will concomitantly improve the design and potentially available concurrency in software systems. To evaluate our hypothesis we have studied all 23 GOF patterns. For 18 patterns out of 23, our hypothesis has held true. Another interesting preliminary result reported here is that for 17 out of these 18 studied patterns, concurrency and synchronization concerns were completely encapsulated in our concurrent design pattern framework

Concurrency by modularity: design patterns, a case in point

General purpose object-oriented programs typically aren't embarrassingly parallel. For these applications, finding enough concurrency remains a challenge in program design. To address this challenge, in the Panini project we are looking at reconciling concurrent program design goals with modular program design goals. The main idea is that if programmers improve the modularity of their programs they should get concurrency for free. In this work we describe one of our directions to reconcile these two goals by enhancing Gang-of-Four (GOF) object-oriented design patterns. GOF patterns are commonly used to improve the modularity of object-oriented software. These patterns describe strategies to decouple components in design space and specify how these components should interact. Our hypothesis is that if these patterns are enhanced to also decouple components in execution space applying them will concomitantly improve the design and potentially available concurrency in software systems. To evaluate our hypothesis we have studied all 23 GOF patterns. For 18 patterns out of 23, our hypothesis has held true. Another interesting preliminary result reported here is that for 17 out of these 18 studied patterns, concurrency and synchronization concerns were completely encapsulated in our concurrent design pattern framework.This article is published as Rajan, Hridesh, Steven M. Kautz, and Wayne Rowcliffe. "Concurrency by modularity: Design patterns, a case in point." In ACM Sigplan Notices, vol. 45, no. 10, pp. 790-805. ACM, 2010. doi: 10.1145/1932682.1869523. Posted with permission.</p