|
Arch ptions
|
|
Suggestions for BSc/MSc Projects
2003/2004
Suggestion
1:
(Note:-
Concluded 2004 at University College London,
resulted in a Journal Article to IEE Proceedings Software in 2005)
Using
ArchOptions to Inform the Selection of Software Architectures Induced by
Middleware: An Empirical Study
1
Supervision & Contact
- Rami
Bahsoon
- Wolfgang
Emmerich, UCL
2
Objectives
The project aims to empirically investigate the
flexibility/stability of software architectures induced by selected
middleware using ArchOptions [1]. The investigation aims to demonstrate a
way to inform the selection of middleware(s) taking into consideration
the added value and the future options they provide to the software
architecture induced. The investigation will give a special attention to
the quantification of options taking the form of contribution to Quality
of Service (QoS) and/or ease of deployment.
3
Motivating Example
As a motivating example from [2], consider a
distributed software architecture that is to be used for providing the back-end
services of an organization. These architectures will be built on
middleware. Depending on which middleware are chosen, different
architectures will be induced [3]. These architectures will have
differences in how well the system is going to cope with changes. For
example, a CORBA-based solution might meet the functional requirements of
a system in the same way as a distributed component-based solution that
is based on a J2EE application server. A notable difference between these
two architectures will be that increasing scalability demands might be
easily accommodated in the J2EE architecture because J2EE primitives for
replication of Enterprise Java Beans can be used, while the CORBA-based
architecture will not easily scale. Thus, when selecting an architecture
the question arises whether an organization wants to invest into an J2EE
application server and its implementation within an organization or
whether it would be better off implementing a CORBA solution. Answering
this question without taking into account the flexibility that the J2EE
solution provides and how valuable this flexibility will be in the
future might lead to making the wrong choice.
For another motivating example, refer to the architectural
stability section of Emmerich [4].
4
Benefits to the interested student(s)
· Familiarize
the interested student(s) with at least two or more middleware
technologies,
· Provide a
“taste” of research in distributed software architectures induced
by middleware,
· Train in
performing empirical studies taking an economic/value-based reasoning
approach,
· Provide a
“taste” of software metrics with the encouragement to develop their own
(more focused and suitable for the architecture/middleware level) as the
project proceeds and motivated by the case under investigation,
5
Pre-requisite
- Preferably
graduate standing,
- Familiarity
with one or more middleware technologies is preferable but not a
must,
- Good
programming and analytical skills,
- Have the
potential and the patience for conducting an empirical work
(training/help will be provided).
6
A Rough Sketch of the Intended Experiment
1. Select one or
more (distributed application) e.g. e-shopping,
2. Specify the
requirements and craft the architecture,
3. Implement the
crafted architecture using two or more middleware technologies (e.g. EJB,
CORBA). Obviously, you need to choose specific technology so that
the comparison can make sense,
4. Specify some
likely changes that may occur in the future. For this project, you need
to focus on changes in QoS and deployment strategies through the
evolution of the software system. You may need to write change
scenarios that exemplify these changes. (Alternatively, you may freeze
some of the requirements specified in (2) and consider these as likely
future changes),
5. Your objective
is to quantify the added value of the architecture’s responsiveness
(induced by the selected middleware) to accommodating these changes. To
achieve (5), you may need to instrument the application to calculate some
metrics (to quantify changes in QoS dimensions and deployment). You
may use or tailor existing metrics with the assumption that
interpretation holds with respect to the architecture. Alternatively, you
may develop your own metrics,
6. Along with point
5, you have to estimate the cost of accommodating these changes. Again,
you may use existing metrics (like COCOMO 2) or develop your own metrics
when necessary,
7. Points (5) and
(6) lead to the quantification of two important parameters of ArcOptions
(namely the cost and value of the architecture responsiveness to the
change). Apply the ArchOption model to understand the options provided by
each architecture induced by the selected middleware. Again, the options
of interest for this case study are on QoS dimensions and ease of
deployment,
8. Report your
results,
9. Interpret and
discuss (8) based on what you have observed and what the ArchOptions model
reported. You may need to report any threats to validity and the
sensitivity of the obtained results to any assumptions made.
7
The Structure of the Student’s Report or her/his Thesis (to-be)
1. Introduction –
Scope, Motivations, and Objectives,
2. Review of basic
middleware technologies utilized in the experiment and their
software architecture use,
3. Experimental
Description
·
Application
to be used,
·
Requirements,
·
Architectures,
·
Change
Scenarios with particular focus on changes in QoS and deployment
strategies,
·
Experimental
Set-up (this includes the experimental assumptions adopted to make the
comparison between the selected middlewares feasible. Also, the adopted
or developed metrics to quantify the changes, instrumentation to quantify
the added value, and ways to estimate the cost to accommodate the
changes,
4. Applying
ArchOptions,
5. Experimental
results,
6. Discussion
(including limitations, sensitivity analysis and threats to validity)
7. Conclusions and
further work.
8
Originality & Possible Contributions
·
Empirical
study of software architecture induced by middleware using economic/
value based- reasoning (first study of its kind) with the prospect of
reporting it to a technical journal- of empirical/maintenance nature
9
Some Selected Readings
(to start with)
|
1.
Bahsoon, R., Emmerich, W.: ArchOptions: A Real Options-Based Model for
Predicting the Stability of Software Architecture. In: Proceedings
of the Fifth Workshops on Economics-Driven Software Engineering
Research, EDSER 5, held in conjunction with the 25 th International
Conference on Software Engineering (2003)
|
|
2.
Bahsoon, R.: Evaluating Software Architectures for Stability: A Real
Options Approach. Research Abstract In: Proceedings of the Doctral
Symposium of the 25 th International Conference on
Software Engineering (2003)
|
|
3.
Di Nitto, E. and Rosenblum, D.: Exploiting ADLs to Specify Architectural
Styles Induced by Middleware Infrastructures. In: Proceedings of the
21st Int'l Conf. on Software Engineering (1999) 13-22
|
|
4.
Emmerich, W.: Distributed Component Technologies and their Software
Engineering Implications. In: Proceedings of the 24th Int.Conference on
Software Engineering, Orlando,
Florida (2002) 537-546
|
|
5.
Emmerich, W.: Software Engineering for Middleware: a roadmap In A.
Finkelstein(ed): The Future of Software Engineering, ACM Press (2000)
|
|
6.
Nuseibeh, B., Kramer, J., Finkelstein, A.: A Framework for Expressing
the Relationships between Multiple View in Requirements Specification.
Transactions of Software Engineering, Vol. 20(10). (1994) 760-773
|
10 Related Links
- ArchOptions
Project web page
Suggestion
2- (Suitable for BSc Project)
- Building
a tool to support ArchOptions: very basic interactive
spreadsheet-like tool to support evaluating software
architectures for stability and evolution. More details will be
provided to the interested student.
|
|
|
Wall
Street Pays Back:
ArchOptions...
People
involved:
Dr Rami
Bahsoon
Prof
Wolfgang Emmerich(University College London)
For your
feedback contact
Dr Rami
Bahsoon
r.bahsoon@cs.bham.ac.uk
|
