Software Engineering - Presentation tier for a BPMS

Author

Presentation tier for a BPMS

Bilal AlSallakh

2005-11-20, 7:57 am

Hi there,

My graudation project is to build a presentation tier for a business
process management system being developed with other student groups.

I'd like to ask about the functional and non-functional requirements
for a good presentation tier and, and what standards are coducted for
it.

It'd be nice if you can refer me to articles or research papers about
this topic

Thanks in Advance

H. S. Lahman

2005-11-20, 6:59 pm

Responding to AlSallakh...

> My graudation project is to build a presentation tier for a business
> process management system being developed with other student groups.

What is the UI paradigm? GUI? Web browser? Command line? Smoke signals?

My point is that before you can design the presentation software you
need a design for the UI that the user will see. The software will then
reflect the designated paradigm for the UI context (e.g., Window/Control
for a GUI or Page/Section/Table for a browser). Thus the paradigm will
determine what abstractions you need.

Let's assume a GUI. The paradigm is Window/Control so those will be the
main abstractions. Thus a Process object with a StartDate attribute
will be represented as a Window instance for Process with a related
text-box Control instance for StartDate. Note that the problem
semantics is reflected solely in things like Window identity and text
labels for titles. IOW, the primary semantics you are representing are
the invariants of the UI paradigm, not the problem being solved.

For UIs most of the detailed characteristics -- fonts, background
colors, modality, etc. -- can be defined once externally in a
configuration file. [Note that this is what commercial window and web
builder tools do. They define the details in an external "resource"
file that is read to initialize generic paradigm objects.]

Once you have the abstractions identified you need to provide an
interface for the problem solution (i.e., your colleagues doing the
business layer) to use. That interface is really defined by their needs
(e.g., "display this Process data") so you need to get requirements from
them. For the interface you can provide a GoF Facade pattern that will
essentially encode/decode their requests into your representation objects.

In providing an interface you need some means of providing identity.
That allows quite different mapping of interface messages to objects in
both the presentation and business layers. However, in the UI case you
also use the identity to map to the external configuration data (e.g.,
all Process windows have blue background). IOW, in a pure message
interface one has {message ID, data identity, data}. The message ID
broadly determines what the presentation layer must do and data identity
defines how the data packet maps to objects in the presentation layer.

[Often the message ID can be employed for data identity when the
interface is very fine grained. However, there is nothing to prevent
the business layer from providing complex data with compound identities
in a single message. You just need to be able to unambiguously
encode/decode the data packet on each side of the interface.]

> I'd like to ask about the functional and non-functional requirements
> for a good presentation tier and, and what standards are coducted for
> it.

You have two sources of functional requirements: the UI design from the
user perspective and the Business layer's needs. You have one source of
nonfunctional requirements: the computing environment, which determines
which UI paradigm to employ and how you talk to the window manager,
network, or whatever.

Note that for a UI traditional nonfunctional requirements like
performance are probably not going to be very important. But others may
be. For example, GUIs may be limited by the number of OS window
instances that can be active at once, necessitating proactive deletion
when done with a display. One of the advantages of decoupling the
presentation layer from the business layer is that one can deal with
unique nonfunctional requirements in isolation from the rest of the
application and can employ techniques optimized for the paradigm.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

Sponsored Links