Advance Software Engineering

Assignment # 1

Submitted by:
Muhammad Usman
70038309
Section - D
Submitted to:
Ma’am Hafiz Maria

Department of Computer Science

THE UNIVERSITY OF LAHORE
 ALPHA Architectural Styles from Architectural Primitives

Introduction Summary:
“Architectural styles codify the recurring architectural design practices, and successful system
organizations. Styles are therefore reusable software architectural idioms and have the potential
to economize software development.”
Although there are many techniques for analyzing and describing styles, Existing software
architecture approaches support abstractions “layered” on top of those provided by
programming languages, thus ensuring continuity and reuse of past investments as newer
abstraction techniques are mapped to existing ones. However, such approaches do little to
improve compositionality of systems. It is widely believed that compositional approaches to
software development (e.g., analogously to how this is done in computer hardware architecture)
are key to constructing large, complex systems. Delivering the full value of architectural design
would, therefore, require that they identify the primitives underlying software architectural
elements. Although low-level communication and programming primitives are used for building
software architectures, there is an almost complete lack of understanding of software
architectural primitives.
This paper proposes a framework for characterization and composition of architectural styles,
called Alfa (assembly language for software architectures), based on a small set of architectural
primitives. Alfa’s characterization of styles identifies their orthogonal aspects and, in turn,
naturally supports composition of style elements. Our approach is based on the use of a point to-
point communication channel, called duct, for interaction among communicating style elements.

The Researches basically used the PIPE AND FILLTER architecture to make the Alfa
Architecture.

 Duct:
A duct is a path of interaction that is used for the transfer of both data and control
Channel-based communication can be easily mapped to other communication models
such as message passing, shared spaces, communication buses, or remote calls.

The main contributions of researchers presented in this paper are:

1. a novel approach for characterization, and composition of architectural styles; and
2. a small and expressive set of architectural primitives for composing elements of
architectural styles.
Literature Summary:
The Researchers has been directly influenced by advances in software architecture, coordination
models and languages, distributed systems, and middleware. For brevity, they focus on the first
two topics here.

 Software architecture: A software architecture allocates system function across its

elements, determines the configuration whereby these elements are organized into the
system, fixes the nature and protocols of interaction required between these elements,
and specifies the data exchanged in these interactions. There are three kinds of
architectural elements, namely, processing, connecting, and data. Architectural styles are
named sets of constraints on these elements and their inter-relationships. Formal
techniques such as Z, PI-calculus, and graph grammars have been used with styles to
provide rigor to their definitions and perform systematic analysis thereupon. However,
such approaches do not consider the synthesis of architectural styles from shared building
blocks. On the other hand, empirical studies of styles including classifications such as and
catalogs such as aid the practitioner in comparing styles for their properties, but do not
identify the shared building blocks of these styles. Comparative studies of styles indicate
that software connectors, i.e. interactions among components, are key determinants of
properties of a style. Our previous work has provided a taxonomy of software connectors,
and identifies ducts, transfer of data, and transfer of control as the building blocks of
software connectors. Recent studies (e.g., Reo) confirm this belief and support the
composition of software connectors from a handful of primitives.

 Coordination models and languages: Coordination is the process of managing

dependencies among software components in a software system. Various coordination
models have emerged, each with its own set of primitives, including message- passing,
shared spaces, communication buses, and point-to-point communication channels. Point-
to-point communication channels are shown to provide more architectural
expressiveness and efficiency than other existing coordination models. Likewise, various
calculi such as process algebras and coalgebras of timed data streams have been
developed to provide rigor to these models and support their analysis.
Researchers work is the first of its kind in recognizing that architectural styles can be
composed from architectural primitives and unique in relating architectural primitives to
a coordination model.
COMET(s), A Software Architecture Style and an Interactors Toolkit for
Plastic User Interfaces

Introduction Summary:
In the vision of ubiquitous computing users live in dynamic environments that change over time.
Interactional, computational as well as communicational resources may arrive and disappear
opportunistically. As these changes cannot always be foreseen at design time, there is a need for
User Interfaces (UIs) to dynamically adapt to the actual context of use (<User, Platform,
Environment>) while preserving usability. Researchers use the term Plasticity to denote this UI
property. In this paper, they provide the designer (in the future the end-user) with tools for
building plastic UIs and for exploring alternative renderings at design time as well as at runtime.
The corner stone is a software architecture style called COMET (Context Modulable widget).
COMET compliant interactors are called COMETs. COMETs are task-based interactors. They group
together presentations that support a particular user’s task. For instance, a set of radio buttons,
a combo-box, a list and a pie menu support the user to “select one option among N”. As a result,
they are gathered in one and the same COMET which purpose is to select one option among N.
In the same way, COMETs based on task operators are defined. For instance, the interleaving
COMET groups together several presentations for rendering interleaving. This can be done by
putting the interleaved subtasks side by side in a certain window, by using multiple windows or
a navigation interactor such as a menu. These two kinds of COMETs rely on the same architectural
style: COMET.
COMET, the proposed architectural style, is fashioned for supporting polymorphism (i.e. multiple
presentations) where presentations can belong to different rendering technological spaces (e.g.
HTML, OpenGL, vocal). The goal of COMET(s) is to sustain the following four requirements:
• Sustaining UI adaptation at any level of abstraction: tasks and concepts, abstract,
concrete and final UI as elicited in model-based approaches.
• The ability of UIs to be simultaneously rendered in several technologies including web and
non-web, WIMP and non-WIMP, and also textual input and voice output.
• The ability of UIs to be dynamically transformed including enrichments with external and
tailored UIs.
• The ability for the user (designer and/or end-user) to explore design alternatives by
substituting presentations of COMETs at design time as well as at runtime.

Literature Summary:
In plasticity, the state of the art can be roughly categorized into three main approaches:
• Model Driven Engineering (MDE)
• Window managers
• Widget toolkits
MDE is probably the area that recently received the most attention. Separation of concerns is the
core principle. A UI is described from different perspectives (task, concepts, abstract UI (AUI),
concrete UI (CUI), final UI (FUI)), each of them giving rise to a specific model. In the same way,
the functional core and the context of use can be described along a set of models. Models are
linked together through mappings.
Mappings convey the widgets rationale (the tasks they support) as well as the UI deployment
among the set of available platforms. So far, MDE has been widely explored for the forward
generation of standardized UIs. Façade investigates another approach: the adaptation is
performed at the windows manager level. Adaptation is fully driven by the end-user who can
dynamically copy/paste/replace parts of the UI. Façade is limited to graphical UIs. It relies on the
widgets toolkit for the introspection mechanisms and the set of available widgets. As in practice
none of these toolkits reaches the task level, adaptation cannot be performed at a high level of
abstraction (task or dialog). Widget toolkits have already extensively been explored. They tackle
specific plasticity issues such as multimodality, polymorphism, or post-WIMP UIs. None of these
covers the tasks operators: sequence, interleaving, or operator, and so on. As a result, all the
transformations changing the way the navigation is rendered are lost (e.g., switching from a
menu to hyperlinks, tabbed panes, blanks or separators). In addition, only some approaches
support extensibility easily. Presentations are mostly mono technological, and adaptation is
neither foreseeable nor controllable.

References:

1. Medvidovic, N., Mehta, N. R., Composing Architectural Styles From Architectural

Primitives
http://sunset.usc.edu/~softarch/Alfa/pubs/Composing.pdf

2. Demeure, A., Calvary, G., Coninx, K., COMET(s), A Software Architecture Style and an
Interactors Toolkit for Plastic User Interfaces
https://doclib.uhasselt.be/dspace/bitstream/1942/8511/1/COMET.pdf